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_ Ordlista 

Trots att manga ar vana att anvanda engelska uttryck sa kan de ibland 
upplevas som ett hinder for att verkligen forsta. Nedanstaende svenska 
begrepp har oversattaren anvant i boken for engelska uttryck som ocksa ar 
vanliga att anvanda i svenska. 


Engelska 

Svenska 

Agile 

Fattrorlig, Agil 

Backlog 

Behovslista, uppgiftslista 

Batch 

Sats 

Burndown chart 

Progressdiagram 

Cadence 

Rytm / Taktslag 

Commit (oneself) 

Forbinda (sig), ata sig 

Daily Scrum 

Dagligt Scrummbte 

Daily standup (meeting) 

Dagligt stauppmote 

Deliver 

Feverera 

Deploy 

Driftsatta 

Development team 

Utvecklingslag 

Epic 

Epos 

Feedback loop 

Aterkopplingsloop 

First-line support 

First-line support 

Item (backlog) 

Uppgift (fran 
behovs/uppgiftslistan) 

Iteration 

Iteration 

Fean 

Slimmad, Fean 

One-piece flow 

Enuppgiftsflode 

Potentially shippable code 

potentiellt leverbar kod 

Product backlog 

Behovslista for produkt 

Pull (work) 

Dra (arbete) 

Pull system 

Pull-system (’’sugsystem”) 

Release 

Feverera / leverans 

Retrospective 

Aterblick 

Scope 

Omfattning 

Scrum of Scrums 

’’Scrum of scrums” 
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SLA 

Overenskommen serviceniva 

Sprint backlog 

Uppgiftslista for sprint 

Stop the line 

Stoppa bandet 

Story point, sp 

Anvandarberattelsepoang, abp 

Support team 

Supportlag 

Swimlane 

Simbana 

Task 

Aktivitet 

Team 

Lag 

Team member 

Lagspelare 

Time-boxed 

Tidsbegransad 

User story 

Anvandarberattelse 

WIP (Work in Progress) 

PA (Pagaende Arbete) 


Scrum-termema ar delvis hamtade fran Krister Kauppis ’’Scrum pa 
svenska”. 
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_ Forord av Mary Poppendieck 

Henrik Kniberg tillhor den sallsynta skaran som kan extrahera essensen i 
en komplicerad situation, separera karnideerna fran tillfalliga distraktioner 
och ge en kristallklar forklaring som ar otroligt latt att forsta. I den har 
boken gor Henrik ett lysande arbete med att forklara skillnaden mellan 
Scrum och Kanban. Han tydliggor att de har metodema endast ar verktyg 
och att det du egentligen vill ha ar en komplett verktygslada med verktyg 
vars anvandning, styrkor och begrasningar du verkligen forstar. 

I den har boken far du reda pa vad Kanban handlar om, dess styrkor och 
begransningar och nar det anvands. Du far ocksa en bra lektion i hur och 
nar du kan bli battre i Scrum — eller i nagot av de andra verktyg som du 
for tillfallet anvander. Henrik klargor att det viktigaste inte ar vilket eller 
vilka verktyg du boijar med utan hur du standigt forbattrar din 
anvandning av dem och att du hela tiden fyller pa din verktygslada. 

Den andra delen, av Mattias Skarin, gor boken annu mer kraftfull genom 
att guida dig genom en verklig situation dar Scrum och Kanban tillampas. 
Har far du exempel pa hur verktygen anvants, bade var for sig och i 
kombination, for att forbattra utvecklingsprocesser. Du kommer att 
upptacka att det inte firms ett ”basta” satt att gora saker. Du maste 
namligen tanka efter sjalv och, baserat pa den egna situationen, sjalv 
rakna ut vad som ar nasta steg mot ett battre satt att utveckla programvara. 


Mary Poppendieck 




Forord av David Anderson 

Kanban bygger pa en mycket enkel ide. Pagaende Arbete (PA) bor 
begransas och nagot nytt bor paborjas forst nar befintligt arbete levereras 
eller dras av en efterfoljande funktion i arbetsprocessen. Ett kanban (eller 
signalkort) innebar att en visuell signal skapas for att indikera att nytt 
arbete kan dras eftersom pagaende arbete inte motsvarar den 
overrenskomna omfattningen. Detta later varken sarskilt revolutionerande 
eller som att det i grunden skulle paverka prestation, kultur, formaga och 
mognad i ett team och dess omgivande organisation. Det som ar 
hapnadsvackande ar att det gor det! Kanban verkar vara en sadan liten 
forandring och anda forandrar det allt i en verksamhet. 

Det vi har insett ar att Kanban ar en metod for forandringsarbete. Det ar 
inte en process eller livscykel for programvaruutveckling eller 
projektledning. Kanban ar ett satt att infora forandring i en befintlig 
programvaruutvecklingsprocess eller projektledningsmetodik. Principen 
for Kanban ar att du boijar med hur du gor nu. Du far forstaelse for din 
nuvarande process genom att kartlagga vardeflodet och foljer sedan 
granserna for PA i vaije steg i den processen. Sedan later du arbete floda 
genom systemet genom att dra arbete nar Kanban-signaler genereras. 

Kanban har visat sig anvandbart for team som arbetar med agil 
programvaruutveckling men det boijar ocksa bli intressant for team som 
har ett mer traditionellt tillvagagangssatt. Kanban infors som en del av ett 
Lean-initiativ for att forvandla kulturen i en organisation och uppmuntra 
standiga forbattringar. 

Eftersom PA ar begransat i ett Kanban-system, tenderar allt som av nagon 
anledning blir blockerat att strama upp systemet. Om en viss mangd 
arbetsuppgifter blockeras stannar hela processen upp. Det far effekten att 
hela teamet och den storre organisationen fokuseras pa att losa problemet, 
hava blockeringarna och aterstalla flodet. 
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Kanban anvander en visuell kontrollmekanism for att folja arbete som 
flodar genom de olika stadierna i vardestrommen. Vanligtvis anvands en 
vit tavla med klisterlappar eller ett elektroniskt kortsystem for vaggen. 
Bast ar nog att anvanda bade och. Den oppenhet som detta genererar 
bidrar ocksa till en kulturell forandring. Agila metoder har bidragit till att 
ge insikt i PA, avslutat arbete och matningar som till exempel hastighet 
(mangden arbete som utfors i en iteration). Kanban gar dock ett steg 
langre och ger insyn i processen och dess flode. Kanban exponerar 
flaskhalsar, koer, foranderlighet och sloseri som alia paverkar 
organisationens resultat i termer av mangd vardefullt levererat arbete och 
tiden for att leverera det. Kanban ger gruppmedlemmar och externa 
intressenter insyn i effekten av sina handlingar (eller overksamhet). Tidiga 
fallstudier visar att Kanban, som sadan, forandrar beteenden och 
uppmuntrar till okad samverkan pa arbetsplatsen. Insynen i och paverkan 
pa flaskhalsar, sloseri och foranderlighet uppmuntrar ocksa till diskussion 
om forbattringar och team borjar snabbt genomfora forbattringar av sin 
process. 

Som ett resultat av detta uppmuntrar Kanban inkrementell utveckling av 
befintliga processer och ett forandringsarbete som generellt ar i linje med 
Lean och agila varden. Kanban kraver inte en radikal revolution av hur 
manniskor fungerar. Snarare uppmuntras gradvis forandring. Det ar 
forandring som forstas och godkanns i samforstand mellan utforama och 
deras medarbetare. 

Genom sitt pull-system uppmuntrar Kanban ocksa fordrojt atagande bade 
vad galler prioritering av nytt arbete och leverans av utfort arbete. Typiskt 
kommer teamen overens om en rytm for prioriteringsmoten med 
intressentema da det bestams vad som ska goras hamast. Dessa moten kan 
hallas ofta eftersom de vanligtvis ar mycket korta. En mycket enkel fraga 
behover besvaras, t.ex. ’’sedan vart forra mote har tva luckor blivit lediga. 
Yar nuvarande cykeltid ar 6 veckor till leverans. Vilka tva saker vill ni 
heist levereras om 6 veckor?”. Detta har en dubbel inverkan: en enkel 
fraga brukar fa ett snabbt och hogkvalitativt svar och det gor motet kort. 
Fragans beskaffenhet betyder att arbetsatagandet fordrojs till sista tillfallet 
att bestamma sig. Detta okar rorligheten genom att hantera forvantningar, 
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korta cykeltider fran atagande till leverans och eliminera omarbetningar 
eftersom risken att prioriteringarna forandras minimeras. 

Ett sista ord om Kanban ar att effekterna av att begransa PA ar att 
cykeltider blir forutsagbara och leveranser mer tillforlitliga. ’’Stoppa 
bandet”-principen for att hantera hinder och buggar verkar ocksa framja 
mycket hog kvalitet och kraftigt minska omarbetningar. 

Emedan allt detta kommer att bli uppenbart med hjalp av de underbart 
tydliga fbrklaringama i denna bok sa kommer det forbli otydligt hur vi 
natt hit. Kanban blev inte uttankt pa en eftermiddag genom nagon 
fantastisk uppenbarelse. Det uppstod snarare successivt under flera ar. 
Manga av de djupa psykologiska och sociologiska effekter som forandrar 
kultur, formaga och mognad hos organisationer kunde man aldrig 
forestalla sig. Snarare blev de upptackta. Flera resultat fran Kanban ar 
icke-intuitiva. Vad som verkar vara ett mycket mekaniskt synsatt — 
begransa PA och dra arbete - visar sig ha djupgaende effekter pa 
manniskor och hur de samverkar och samarbetar med varandra. Varken 
jag eller nagon annan som arbetade med Kanban i dess vagga forvantade 
sig detta. 

Jag utovade det som blev Kanban som ett forhallningssatt till forandring 
som skulle mota minimalt motstand. Detta stod klart for mig redan 2003. 
Jag efterstravade ocksa de mekaniska fordelama. Nar jag vid den tiden, 
genom tillampning av Lean-metoder, upptackte att om hanteringen av AP 
verkade vettig sa skulle begransningen av det var vettigare: det 
eliminerade tiden att hantera det. 2004 bestamde jag mig darfor for att 
forsoka genomfora ett pull-system fran grunden. Jag gavs tillfalle nar en 
chef pa Microsoft bad mig hjalpa honom att hantera forandringar i hans 
team som arbetade med underhall och uppgraderingar av interna IT- 
applikationer. Det forsta genomforandet var baserat pa restriktionsteorins 
pull-system, kallat Drum-Buffer-Rope. Det var en stor framgang: 
cykeltiden minskade med 92%, genomstromningen okade med mer an 3 
ganger och predikterbarheten (forfallodagsprestanda) lag pa mycket 
acceptabla 98%. 

Ar 2005 overtalade Donald Reinertsen mig att infora ett fullt utvecklat 
Kanban-system. Jag fick mojligheten 2006 nar jag tog hand om 
programvaruavdelningen pa Corbis i Seattle. 2007 borjade jag redovisa 
resultaten. Den forsta presentationen var pa Lean New Product 
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Development Summit i Chicago i maj 2007. Jag foljde upp det med ett 
oppet mote pa Agile 2007 i Washington DC i augusti samma ar. 25 
personer deltog och tre av dem var fran Yahoo!: Aaron Sanders, Karl 
Scotland och Joe Arnold. De akte hem till Kalifornien, Indien och 
Storbritannien och inforde Kanban i sina team som redan kampade med 
Scrum. De startade ocksa en diskussionsgrupp pa Yahoo! som i skrivande 
stund har nastan 800 medlemmar. Kanban borjade spridas och ’’early 
adpoters” pratade om sina erfarenheter. 

Nu, 2009, okar inforandet av Kanban och allt fler rapporter strommar i. Vi 
har lart oss mycket om Kanban under de senaste 5 aren och vi fortsatter 
att lara oss mer varje dag. Jag har fokuserat mitt eget arbete pa att utfora 
Kanban, skriva om Kanban, tala om Kanban och tanka pa Kanban for att 
battre forsta och forklara det for andra. Jag har medvetet tagit avsteg fran 
att jamfora Kanban med befintliga agila metoder, aven om visst arbete 
agnades 2008 at att forklara varfor Kanban fortjanade att betraktas som en 
agil-kompatibel metod 

Jag har overlamnat at andra med storre erfarenhet att svara pa fragor som 
”Hur ar Kanban jamfort med Scrum?” Jag ar sa nojd att Henrik Kniberg 
och Mattias Skarin har dykt upp som ledare i detta avseende. Du, 
kunskapsarbetare i amnet, behover information for att fatta valgrundade 
beslut och komma vidare i arbetet. Henrik och Mattias servar dina behov 
pa ett satt som jag aldrig skulle kunna. Jag ar sarskilt imponerad av 
Henriks genomtankta jamforelsestrategi och hans sakliga och icke 
pastridiga, balanserade framstallning. Hans teckningar och illustrationer 
ar sarskilt insiktsfulla och besparar dig ofta fran att lasa atskilliga sidor 
text. Mattias fallstudie ar viktigt eftersom det visar att Kanban ar mycket 
mer an teori och det visar genom exempel pa vilket satt det kan vara 
anvandbart for dig i din organisation. 

Jag hoppas att du tycker om denna bok som jamfor Kanban med Scrum 
och att det ger dig storre insikt i agilt i allmanhet och bade Kanban och 
Scrum i synnerhet. Om du vill veta mer om Kanban besok var 
community, The Limited WIP Society, http://www.limitedwipsociety.org/ 

David J. Anderson 


Sequim, Washington, USA 
8 juli, 2009 




Introduktion 

I vanliga fall skriver vi inte bocker. Yi foredrar att lagga var tid djupt 
nedgravda i utmaningen att hjalpa kunder att optimera, debugga och 
refaktorisera sina utvecklingsprocesser och organisationer. Pa senare tid 
har vi dock noterat en trend och vi skulle vilja dela med oss av vara tankar 
kring det. Har ar en typisk situation: 

Helena "Nu har vi antligen fatt fullt grepp om Scrum!" 

Peter "Gar det bra da?" 

Helena "Ja, det ar ju battre an det vi hade innan..." 

Peter "Men...?" 

Helena "...jo, du forstar, vi har borjat med support och underhall 
nu..." 

Peter "Ja, och...?" 

Helena "Ja, alltsa, vi gillar allt det dar med att sorteringsprioritera 
behovslistan, sjalvorganiserande utvecklingsteam, dagliga 
avstamningsmoten, aterblick, och sa vidare..." 

Peter "Sa vad ar problemet?" 

Helena "Vi misslyckas med malen i varenda sprint." 

Peter "Varfor da?" 

Helena "For att vi tycker det ar svart att binda oss till en 2- 

veckorsplan. Iterationerna har ingen speciell betydelse 
langre. Vi bara jobbar pa med det som ar viktigast for 
dagen. Vi kanske skulle kora 1-veckors-sprintar istallet?" 

"Skulle ni kunna binda er till en veckas arbete? Har ni 
mojlighet att fokusera och arbeta i fred i en vecka?" 
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Helena "Nej, inte direkt. Det dyker ju upp saker hela tiden. Kanske 
endags-sprintar..." 

Peter "Tar era uppgifter mindre an en dag att utfora?" 

Helena "Na, ibland tar de flera dagar..." 

Peter "Sa endags-sprintar skulle inte heller fungera. Har ni 
funderat pa att skippa sprintar helt och hallet?" 

Helena "Arligt talat, ja, det skulle vi vilja. Men ar inte det emot 
principerna i Scrum?" 

Peter "Scrum ar bara ett verktyg. Ni bestammer sjalva hur och 
nar ni anvander det. Lat er inte styras av verktyget." 

Helena "Men vad ska vi gora da?" 

Peter "Har du hort talas om Kanban?" 

Helena "Vad ar det? Vad ar det for skillnad mellan det och 
Scrum?" 

Peter "Har. Las den har boken." 

Helena "Men jag gillar ju resten av Scrum. Maste vi byta nu?" 

Peter "Na, man kan kombinera metoderna!" 

Helena "Va? Hur da?" 

Peter "Las bara vidare..." 


xiv 
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Syfte med denna bok 

Om du ar intresserad av agil systemutveckling har du formodligen hort 
talas om Scrum och du kan ocksa ha hort talas om Kanban. En fraga som 
vi hor allt oftare ar ”sa vad ar Kanban, och hur fungerar det i jamforelse 
med Scrum?” Var kompletterar de varandra? Finns det nagra potentiella 
konflikter? 

Syftet med denna bok ar att latta dimman sa att du kan rakna ut hur 
Kanban och Scrum kan vara anvandbart i din situation. 

Beratta for oss om vi lyckas! 
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_ Del I - Jamforelse 

Den forsta delen av den hdr boken dr ettforsdk att gora en objektiv och 
praktisk jamforelse mellan Scrum och Kanban. Det dr en nagot 
uppdaterad version av originalartikeln "Kanban vs. Scrum” fran april 
2009. Den artikeln blev popular sa jag bestamde mig for att gora en bok 
av den och be min kollega Mattias att krydda den med en "from the 
trenches ’’-fallstudie fran en av vara kunder. Bra grejer! Hoppa garna 
direkt till del II om du vill borja med fallstudien. Jag tar inte ilia upp. 

Ok, life da kanske. 

/Henrik Kniberg 
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Vad ar Scrum och Kanban egentligen? 

Ok, lat oss forsoka summera Scrum och Kanban pa mindre an 100 ord 
var. 


Scrum i ett notskal 


• Dela upp organisationen i sma tvarfunktionella, sjalv- 
organiserande lag. 



Dela upp arbetet i en lista med sma, konkreta resultat. Sortera 
listan efter prioritet och uppskatta den relativa insats som kravs 
for vaije post. 
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• Dela upp tiden i korta iterationer med fast langd (vanligen 1—4 
veckor) med potentiellt levererbar kod som demonstreras efter 
vaije iteration. 

januari -I-1-1-1-1-1-1-1-t* *- april 

» I I 1 I I I 4 

B a a g □ □ g g 

• Optimera leveransplanen och uppdatera prioriteringama i 
samrad med kunden baserat pa insikter som framkommit fran 
granskning av leveransen efter vaije iteration. 

• Optimera processen genom aterblick efter varje iteration. 

Sa istallet for att en stor grupp spenderar lang tid pa att bygga en stor 
sak har vi ett litet lag som tillbringar en kort tid med att bygga en liten 
sak men som integrerar regelbundet for att se helheten. 

122 ord... nara nog. 

Kolia in "Scrum och XP fran Trenches" for mer information. Boken ar 
gratis att lasa pa natet. Jag kanner forfattaren och det ar en trevlig kille :o). 

http://www.crisp.se/ScrumAndXpFromTheTrenches.html 

Kolia in http://www.crisp.se/scrum for fler lankar om Scrum. 

Kanban i ett notskal 


• Visualisera arbetsflodet 

o Dela upp arbetet i bitar, skriv varje post pa ett kort och 
satt pa vaggen. 

o Anvand namngivna kolumner for att illustrera var i 
flodet vaije arbetspost befinner sig. 

• Begransa pagaende arbete (PA) - tilldela tydliga granser for 
hur manga uppgifter som samtidigt kan paga i vaije arbetssteg. 




Vad ar Scrum och Kanban egentligen? 


Mat ledtiden (genomsnittlig tid for att slutfora en arbetspost — 
kallas ibland “cykeltid”), optimera processen sa att ledtiden blir 
sa kort och forutsagbar som mojligt. 



Anvandbara Kanban-lankar samlar vi pa http://www.crisp.se/kanban. 
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Hur forhaller sig Scrum och 
Kanban till varandra? 


Scrum and Kanban ar processverktyg 


Verktyg - vad som heist som anvands som ett medel for att utfora en 
uppgift eller for att uppna ett syfte. 

Process = hur du arbetar. 

Scrum och Kanban ar processverktyg i den meningen att de hjalper dig att 
arbeta mer effektivt genom att, till en viss grad, beratta for dig vad du ska 
gora. Java ar ocksa ett verktyg; det erbjuder ett enklare satt att 
programmera en dator. En tandborste ar ett annat verktyg; det hjalper dig 
att komma at tandema sa att du kan rengora dem. 

Jamfor verktyg for att forsta, inte for att doma 


Kniv eller gaffel — vilket verktyg ar bast? 


Ratt meningslos fraga, inte sant? Det beror ju pa situation. Om du ska ata 
kottbullar sa ar formodligen gaffeln bast. For att hacka svamp sa ar nog 
kniven bast. For att trumma pa bordskanten sa funkar nog vilken som. Om 
du ska ata en kottbit sa vill du nog anvanda bada verktygen tillsammans. 
Till ris... tja... somliga foredrar gaffel, andra foredrar pinnar. 
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Sa nar vi jamfor olika verktyg med varandra sa bor vi vara forsiktiga. 
Jamfor for att forsta, inte for att doma. 

Inget verktyg ar fullstandigt, inget verktyg ar 
perfekt 


Scrum och Kanban ar, precis som alia andra verktyg, varken perfekta eller 
fullstandiga. De talar inte om allt som du maste gora; de ger dig bara vissa 
begransningar och riktlinjer. Scrum, till exempel, begransar dig till att 
anvanda tidsbegransade iterationer och tvarfunktionella lag. Kanban 
begransar dig till att anvanda synliga tavlor och genom langden pa kon. 

Intressant nog sa ar vardet av ett verktyg just att det begransar dina 
mojligheter. Ett processverktyg som tillater dig att gora precis vad som 
heist ar inte sarskilt anvandbart. En sadan process skulle vi kunna kalla 
”Gor hur du vill” eller varfor inte ”Gor ratt”. ”Gor ratt”-processen 
fungerar garanterat; det ar universallosningen! For om den inte fungerar 
sa har du uppenbarligen inte foljt processen :o) 

Anvander du ratt verktyg sa kommer det hjalpa dig att lyckas men det 
kommer inte att garantera framgang. Det ar latt att forvaxla ett 
lyckat/misslyckat projekt med ett lyckat/misslyckat verktyg. 

• Ett projekt kan lyckas tack vare ett fantastiskt verktyg. 

• Ett projekt kan lyckas trots ett vardelost verktyg 

• Ett projekt kan misslyckas pa grand av ett vardelost verktyg 

• Ett projekt kan misslyckas trots ett fantastiskt verktyg 

Scrum foreskriver mer an Kanban 


Ett satt att jamfora verktyg ar hur manga regler de har. Foreskrivande 
betyder ”fler regler att folja” och adaptiv betyder ’’farre regler att folja”. 
100 % foreskrivande betyder att du inte behover anvanda hjarnan; det 
firms regler for allt. 100 % adaptiv betyder ”Gor hur du vill”, det firms 
inga regler eller begransningar alls. Du halier sakert med om att 
extremerna ar ratt lojliga. 
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Agila metoder kallas ibland for lattviktiga metoder just for att de ar 
mindre foreskrivande an traditionella metoder. Faktum ar att den forsta 
grundsatsen i manifestet for agil utveckling ar ’’individer och interaktioner 
framfor processer och verktyg”. 

Bade Scrum och Kanban ar valdigt adaptiva, men relativt sett ar Scrum 
mer foreskrivande an Kanban. Scrum har fler begrasningar och ger 
darmed mindre utrymme for altemativ. Ett exempel ar att Scrum 
foreskriver tidsbegransade iterationer. Det gor inte Kanban. 

Lat oss jamfora med nagra andra processverktyg pa foreskrivande- 
adaptiv-skalan: 



RUP ar ratt sa foreskrivande - den har over 30 roller, over 20 aktiviteter 
och over 70 dokument; en overvaldigande massa saker att lara sig. Det ar 
forvisso inte meningen att du ska lara dig allt. Tanken ar att du ska valja 
ut en lamplig delmangd som passar projektet. Tyvarr verkar det vara ratt 
sa svart i praktiken: ”Hmmm... behover vi dokumentet Configuration 
audit findings! Behover vi rollen Change control manager ? Ingen 
aning, det ar bast vi behaller dem uti fall att.” Det har kan vara en orsak 
till att RUP-anpassningar ofta blir ratt tungviktiga jamfort med agila 
metoder som Scrum och XP. 

XP (extreme Programming) ar ratt sa foreskrivande jamfort med Scrum. 
Det omfattar det mesta i Scrum plus ytterligare ett antal ratt sa specifika 
ingenjorsmetoder sasom testdriven utveckling och parprogrammering. 
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Scrum ar mindre foreskrivande an XP eftersom det inte dikterar nagra 
speciella ingenjorsmetoder. Scrum ar dock mer foreskrivande an Kanban 
eftersom det pabjuder iterationer och tvarfunktionella lag. 

En av de storsta skillnaderna mellan Scrum och RUP ar att i RUP far du 
for mycket och forvantas ta bort det du inte behover. I Scrum far du for 
lite och forvantas lagga till det som saknas. 

Kanban lamnar nastan allt oppet. Det enda tvingande ar ’’Visualisera 
arbetsflodet” och ’’Begransa PA”. Inte sa langt Iran ”Gor hur du vill” men 
likval forvanansvart kraftfullt. 

Begransa dig inte till ett verktyg! 


Blanda och kombinera verktyg som du vill! Jag kan till exempel knappast 
forestalla mig ett framgangsrikt Scrum-lag som inte ocksa inkluderar de 
fiesta delama i XP. Manga Kanban-lag anvander dagliga stauppmoten (en 
Scrum-sedvana). Vissa Scrum-lag skriver en del av uppgiftema i 
behovslistan (’’backlog”) som anvandningsfall (en RUP-sedvana) eller 
begransar kolangden (en Kanban-sedvana). Gbr det som funkar for er. 

Miyamoto Musashi, en samuraj som levde pa 1600-talet och som var 
beromd for sin teknik att faktas med tva svard, uttryckte det val: 



Var dock uppmarksam pa begransningama i varje verktyg. Om du 
exempelvis anvander Scmm och bestammer dig for att sluta med 
tidsbegransade iterationer (eller nagon annan central del av Scmm) sa sag 
inte att du foljer Scmm. Scmm ar minimalistiskt som det ar. Om du tar bort 
saker och fortfarande kallar det Scmm sa blir begreppet sa smaningom 
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meningslost och forvirrande. Kalla det ’’Scrum-inspirerat” eller ”en 
delmangd av Scrum” eller varfor inte ’’Scrummigt” :o) 




3 

Scrum foreskriver roller 

Scram foreskriver 3 roller: produktagare (satter produktvision och 
prioriteringar), lag (implementerar produken) och Scram Master (tar bort 
hinder och ger processledning). 

Kanban foreskrivr inte nagra roller alls. 

Det betyder inte att du inte kan eller ska ha en produktagarroll i Kanban. 
Det betyder bara att du inte maste. I bade Scram och Kanban ar det fritt 
fram att lagga till de roller du behover. 

Var dock forsiktig nar du lagger till roller. Sakerstall att ytterligare roller 
faktiskt okar vardet och inte star i konflikt med andra delar i processen. Ar 
du saker pa att du behover den dar projektledarrollen? I ett stort projekt 
kanske det ar en ypperlig ide, det ar kanske den person som hjalper till att 
synka flera lag och produktagare med varandra. I ett litet projekt kan den 
rollen vara rent sloseri, eller annu varre, kan leda till suboptimering och 
detaljstyming. 

Det generella tankesattet i bade Scrum och Kanban ar “less is more”. Sa 
nar du ar osaker: boija med mindre. 

I resten av boken anvander jag termen “produktagare” for att representera 
den som satter prioriteringarna for ett lag, oavsett vilket process som 
anvands. 
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Scrum foreskriver 
_tidsbegransade iterationer 

Scrum baseras pa tidsbegransade iterationer. Du kan valja langd pa 
iterationen men den allmanna iden ar att bibehalla langden pa vaije 
iteration over en langre period och darmed etablera en rytm. 

• Borjan av en iteration: En iterationsplan skapas, dvs. laget drar 
ett specifikt antal uppgifter fran behovslistan for produkten 
baserat pa produktagarens prioriteter och hur mycket laget tror att 
de kan slutfora i en iteration 

• Under iterationen: Laget fokuserar pa att slutfora de uppgifter 
som de har forbundit sig att slutfora. Iterationens omfattning ar 
fixerat. 

• Slutet av en iteration: Laget demonstrerar fungerande kod for 
relevanta intressenter. Idealt ar detta potentiellt leveransklar kod 
(dvs. testad och fardig att kora). Darefter gor laget en aterblick 
for att diskutera och forbattra processen. 

En Scrum-iteration ar alltsa en enstaka tidsbegransad rytm som 
kombinerar tre olika aktiviteter: planering, processforbattring och (idealt) 
leverans. 

I Kanban foreskrivs inte tidsbegransade iterationer. Du kan valja nar du 
vill planera, processforbattra och leverera. Du kan valja att gora dessa 
aktiviteter regelbundet (’’leverans varje mandag”) eller vid behov 
(’’leverans nar vi har nagot anvandbart att leverera”). 

Lag #1 (enkel rytm) 

“Vi gor Scrum-iterationer” 


15 



161 Kanban and Scrum - det bAsta av tvA vArldar 





Lag #2 (tre rytmer) 

“Vi har tre olika rytmer. Vaije vecka slapper vi det som ar redo for 
leverans. Varannan vecka har vi planeringsmoten och updaterar 
prioriteringar och leveransplaner. Var fjarde vecka har vi aterblicksmoten 
for att justera och forbattra var process” 




Lag #3 (framst handelsestyrt) 

“Vi kor igang ett planeringsmote sa fort vi borjar fa ont om saker att gora. 
Vi paboijar en leverans sa fort det finns ett antal Minsta Saljbara 
Funktioner (MSF) som ar klara for leverans. Vi startar en spontan 
kvalitetsdiskussion nar vi stoter pa samma problem tva ganger. Vi gor 
ocksa en mer djuplodande aterblick var fjarde vecka.” 
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Kanban begransar PA per tillstand, 
_Scrum begransar PA per iteration 

I Scrum visar sprintens uppgiftslista vilka uppgifter som ska slutforas i en 
pagande iteration (=”sprint” i Scrum). Detta representeras ofta med kort 
pa en vaggyta som kallas Scrum-tavla eller uppgiftstavla. 

Sa vad ar skillnaden mellan en Scrum-tavla och en Kanban-tavla? Yi 
boijar med ett trivialt projekt och jamfor de bada: 




Att gora 

Pagaende 

Klart :o) 

m 


S 


FLODE 


Kanban-tavla 


Att gora 

Pagaende 

2 

Klart :o) 





FLODE 


I bada fall halier vi koll pa ett antal uppgifter som ror sig framat i ett 
arbetsflode. Vi har valt tre tillstand: att gora, pagaende och klart. Du kan 
valja vilka tillstand du vill - vissa lag lagger till tillstand som integration, 
test, leverans, etc. Glom dock inte ’’less is more”-principen. 

Vad ar da skillnaden mellan de har tva exempeltavlorna? Jepp - den lilla 
2:an i den mellersta kolumnen pa Kanban-tavlan. Det ar allt. Den 2:an 
betyder ”det far inte finnas mer an 2 uppgifter i den har kolumnen i varje 
givet ogonblick”. 

I Scrum finns det ingen regel som hindrar laget att placera alia uppgifter i 
pagaende-kolumnen samtidigt. Det finns dock en implicit grans eftersom 
iterationen har en fixerad omfattning. I det har fallet ar den implicita 
gransen 4 per kolumn eftersom det bara finns 4 uppgifter pa hela tavlan. 
Sa Scrum begransar PA indirekt medan Kanban gor det direkt. 

Tids nog lar sig de fiesta Scrum-lag att det ar en dalig ide att ha for manga 
samtidigt pagaende uppgifter och utvecklar en kultur dar man forsoker 
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slutfora pagaende uppgifter innan nya paboijas. Det finns till och med de 
som beslutar att explicit begransa antalet uppgifter som far finnas i 
pagaende-kolumnen och sa - tadaaa! - Scrum-tavlan har blivit en 
Kanban-tavla! 

Sa bade Scrum och Kanban begransar PA men pa olika satt. Scrum-lag 
mater vanligtvis hastighet - hur manga uppgifter (eller motsvarande 
enheter sasom ’’historiepoang”) som slutfors per iteration. Nar laget 
kanner till sin hastighet sa blir det deras PA-grans (eller atminstone en 
vagledning). Ett lag som har en snitthastighet pa 10 kommer vanligtvis 
inte ta in mer an 10 uppgifter (eller story-poang) i en sprint. 

Sa i Scrum begrdnsas PA per tidsenhet. 

I Kanban begrdnsas PA per tillstand. 

I Kanban-exemplet ovan far det finnas hogst 2 uppgifter i tillstandet 
’’pagaende” vid vaije givet ogonblick i tiden, oavsett vad rytmen ar. Du 
maste valja vilken grans som galler for vilket tillstand men den allmanna 
iden ar att begrasna PA for samtliga tillstand, med borjan sa tidigt som 
mojligt och avslut sa sent i vardekedjan som mojligt. I exemplet ovan 
borde vi overvaga att aven satta en PA-grans for ”att gora”-kolumnen 
(eller vad du nu kallar in-kon). Nar vi har satt PA-granserna kan vi boija 
mata och forutsaga ledtid, dvs. snittiden for en uppgift att forflytta sig hela 
vagen over tavlan. Med forutsagbara ledtider kan vi forbinda oss till SLA 
(service-level agreements) och gora realistiska leveransplaner. 

Om storleken pa uppgifterna varierar kraftigt kan du overvaga att istallet 
satta PA-granser i termer av story-poang eller nagon annan enhet som du 
anvander. Det finns lag som investerar tid i att bryta ner uppgifter till 
ungefar samma storlek och minska tiden som laggs pa att estimera saker 
(man kan till och med anse tidsestimering som sloseri). Det ar lattare att 
skapa ett valflytande system om uppgifterna ar av ungefar samma storlek. 




Tank om det fanns reglage for matama ovan och att du kunde konfigurera 
din process bara genom att vrida pa reglagen. ”Jag vill ha hog kapacitet, 
kort ledtid, hog kvalitet och hog predikterbarhet. Sa jag vrider rattarna till 
10, 1, 10 och 10.” 

Skulle inte det vara toppen? Tyvarr finns det inga sadana direkta 
kontrollmekanismer. Inte vad jag vet i alia fall. Sag garna till om du hittar 
nagra. 

Vad vi istallet har ar ett gang indirekta kontroller. 


■ MSnga smS team 

■ Mega AP-granser 

■ LSnga iterationer 

■ Mycket planering 


Bade Scrum och Kanban ar empiriska i det avseende att du forvantas 
experimentera med processen och anpassa den till din omgivning. Faktum 
ar att du maste experimentera. Varken Scrum eller Kanban har alia svar - 
de ger dig bara ett antal grundlaggande begransningar for att tvinga dig till 
processforbattring. 
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• Scrum sager att man ska ha tvarfunktionella lag. Sa vem ska vara 
i vilket lag? Vet inte, experimentera. 

• Scrum sager att laget valjer hur mycket arbete som tas in i 
sprinten. Sa hur mycket ska de ta in? Yet inte, experimentera. 

• Kanban sager att du ska begransa PA. Sa vad ar gransen? Vet 
inte, experimentera. 

Som jag tidigare namnt medfor Kanban farre begransningar an Scrum. 
Det betyder att du far fler parametrar att fundera kring, fler reglage att 
vidra pa. Det kan vara bade en nackdel och en fordel beroende pa 
situation. Nar du oppnar dialogrutan med installningar i en applikation, 
foredrar du da 3 justerbara alternativ eller 100 justerbara altemativ? 
Troligtivs nagot daremellan. Det beror pa hur mycket du maste justera och 
hur val du beharskar applikationen. 

Lat oss anta att vi sanker PA-gransen baserat pa hypotesen att det kommer 
att forbattra processen. Vi mater sedan hur saker som kapacitet, ledtid, 
kvalitet och predikterbarhet forandras. Vi drar slutsatser fran resultaten 
och sedan andrar vi pa nagra andra saker och pa satt genomfor vi standiga 
forbattringar av processen. 

Det finns manga namn for det har. Kaizen (standiga forbattringar pa Lean- 
sprak), Inspektera och Anpassa (Scrum-sprak), Empirisk Processkontroll, 
eller varfor inte Den Vetenskapliga Metoden. 

Den mest kritiska delen i det har ar aterkopplingsloopen. Andra nagot => 
Ta reda pa hur det gick => Lar av det => Andra nagot igen. Generellt sett 
vill du ha en sa kort aterkopplingsloop som mojligt sa att du kan anpassa 
processen snabbt. 

I Scrum ar sprinten den grundlaggande aterkopplingsloopen. Det finns 
dock flera, sarskilt om du kombinerar det med XP: 
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Nar det gors ratt sa ger Scram + XP en mangd vardefulla 
aterkopplingsloopar. 

Den innersta aterkopplingsloopen, parprogrammering, har en 
aterkopplingstid pa ett par sekunder. Defekter hittas och rattas inom nagra 
sekunder fran att de skapas (’’Vanta, skulle inte den dar variablen vara 
3?”). Det har ar ’’bygger vi det ratt?”-aterkopplingen. 

Den yttre aterkopplingsloopen, sprinten, ger oss en aterkopplingstid pa ett 
par veckor. Det har ar ’’bygger vi ratt saker?”-aterkopplingen. 

Kanban da? Tja, forst och framst kan du (och borde nog) stoppa in alia 
ovanstaende feedbackloopar i processen oavsett om du anvander Kanban 
eller ej. Kanban ger dig sedan nagra mycket anvandbara realtidsmatetal: 

• Genomsnittlig ledtid. Uppdateras varje gang en uppgift nar 
“Klart” (eller vad du nu kallar den hogersta kolumnen). 

• Flaskhalsar. Typiska symptom ar att kolumn X ar fylld med 
uppgifter samtidigt som kolumn X+l ar tom. Leta efter 
’’luftbubblor” pa tavlan. 

Det trevliga med realtidsmatningar ar att du kan valja langd pa din 
aterkopplingsloop baserat pa hur ofta du onskar analysera matningarna 
och gora forandringar. For lang aterkopplingsloop innebar att din 
processforandring blir langsam. For kort aterkopplingsloop innebar att 
processen inte hinner stabilisera sig mellan forandringama vilket kan leda 
till sammanbrott. 

Faktum ar att langden pa aterkopplingsloopen ar en av de saker du kan 
experimentera med... som en slags meta-aterkopplingsloop. 

OK, jag slutar nu. 

Exempel: Experimentera med PA-granser i Kanban 

En av de typiska “justeringspunktema” i Kanban ar PA-gransen. Sa hur 
vet man att man fatt ratt niva? 

Anta att vi har ett lag med 4 personer och att vi bestammer oss for att 
boija med en PA-grans pa 1. 
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£ 

Pagaende 

Klart :o) 
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Sa fort vi boijar arbeta pa en uppgift sa far vi inte borja pa en ny uppgift 
forran den forsta ar klar. Sa den kommer att bli gjord ratt fort. 

Toppen! Men sedan visar det sig att det inte ar rimligt att alia 4 ska arbeta 
pa samma uppgift (i den har enkla situationen), sa vi har alltsa personer 
som sitter sysslolosa. Om det bara hander da och da sa ar det inga 
problem men om det hander regelbundet blir konsekvensen att den 
genomsnittliga ledtiden kommer att oka. 

Sa om en PA-grans pa 1 var for langsamt, hur vore det att oka den till 8? 


X 

Pagagide 

Klart :o) 
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Det funkar battre en stund. Yi upptacker att, i genomsnitt, sa far vi mer 
gjort om vi arbetar i par. Sa med ett 4-personerslag har vi vanligtvis 2 
pagaende uppgifter vid varje givet ogonblick. En PA-grans pa 8 ar bara en 
ovre grans sa att ha farre pagaende uppgifter gar utmarkt! 

Ponera nu att vi far problem med integrations servern sa att vi inte kan 
slutfora nagra uppgifter (var definition av ’’Klart” inbegriper integration). 
Sant hander ibland, eller hur? 
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Pagaende 

8 

Klart :o) 
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ffl 

ED 

C Problem med A 

integrationsservem. 

_ Kan inte avsluta D & E! 


Vi arbetar pS F & G 
istallet! 


Eftersom vi inte kan slutfora uppgift D och E boijar vi arbeta pa uppgift 
F. Vi kan inte integrera den heller sa vi drar en ny uppgift G. Efter ett tag 
nar vi Kanbangransen — 8 uppgifter i ’’Pagaende”. 



Vid det har laget kan vi inte ta in tier uppgifter. Hdrrni, det ar bast att vi 
fixar den dar forbaskade integrationsservem! PA-gransen har fatt oss att 
reagera och att losa flaskhalsen istallet for att bara lagga en massa 
oavslutat arbete pa hog. 

Det ar bra. Men om PA-granser var 4 sa hade vi reagerat mycket tidigare 
och darmed fatt en battre genomsnittlig ledtid. Det ar en balansgang. Vi 
mater genomsnittlig ledtid och fortsatter att optimera var PA-grans for att 
optimera ledtiden: 
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Efter ett tag upptacker vi kanske att uppgifter laggs pa hog i ”Att gora”. 
Kanske ar det dags att satta en PA-grans dar ocksa da. 

Varfor behover vi forresten en “Att gora”-kolumn? Tja, om kunden alltid 
fanns tillganglig och kunde beratta for laget vad de ska gora harnast sa 
fort de undrar da skulle ”Att gora”-kolumnen inte behovas. Men i det har 
fallet ar kunden inte alltid tillganglig sa ”Att gora”-kolumnen ger teamet 
en liten buffert att plocka arbete fran. 

Experimentera! Eller, som Scrumologema sager, Inspektera och Anpassa! 
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Scrum motstar forandringar inom en 
_iteration 

Anta att din Scrum-tavla se ut sa har: 


Att gora 
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Klart :o) 
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Vad hander om nagon dyker upp och vill lagga till E till tavlan? 

Ett Scrum-lag kommer vanligtvis att saga nagot i stil med ”Nej, tyvarr, vi 
har forbundit oss att gora A+B+C+D i den har sprinten. Men var sa god 
att lagg till E till behovslistan for produkten. Om produktagaren tycker att 
den har hog prioritet sa kommer vi att ta in den i nasta sprint.” Sprintar 
med ratt langd ger laget precis tillrackligt med fokuserad tid for att fa 
nagot gjort samtidigt som produktagaren regelbundet tillats hantera och 
uppdatera prioriterigar. 

Sa vad gor da ett Kanban-lag? 
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Ett Kanban-lag kanske sager “Var sa god och lagg till E till Att gora- 
kolumnen. Maxgransen ar dock 2 uppgifter for den kolumnen sa du maste 
i sa fall ta bort C eller D. Yi arbetar just nu pa A och B men sa fort vi har 
kapacitet kommer vi att plocka in den oversta uppgiften Iran Att gora”. 

Sa svarstiden (tiden det tar att reagera pa forandringar i prioritering) i ett 
Kanban-lag ar den tid det tar tills kapacitet blir tillganglig, enligt den 
allmanna principen ”en uppgift ut = en uppgift in” (drivs av PA- 
granserna). 

I Scrum ar responstiden i genomsnitt halva sprint-langden. 

I Scrum kan inte produktagaren rora Scrum-tavlan eftersom laget har 
forbundit sig till ett specifikt antal uppgifter i iterationen. I Kanban maste 
du etablera dina egna spelregler for vem som far andra vad pa tavlan. 
Typiskt ger man produktagaren nagon slags ”Att gora”-, ’’Redo”-, 
’’Uppgifter”- eller ”Foreslagna”-kolumn langst till vanster dar hon kan 
gora andringar nar hon vill. 

De har tva ansatserna ar dock inte uteslutande. Ett Scrum-lag far besluta 
att produktagaren tillats andra prioriteringar under pagaende sprint (trots 
att det normalt anses vara ett undantag). Och ett Kanban-lag far besluta att 
infora restriktioner for nar prioriteringar far andras. Ett Kanban-lag kan 
till och med bestamma sig for att anvanda tidsbegransade iterationer med 
faststallt atagande precis som i Scrum. 
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Scrum-tavlan nollstalls efter 
_varje iteration 

I olika stadier av en sprint ser en Scrum-tavla typiskt ut sa har. 


Scrum: Sprintens forsta dag Scrum: Mitt i sprinten 


Scrum: Sprintens si: 


Nar en sprint ar avklarad rensas tavlan - alia uppgifter tas bort. En ny 
sprint paboijas och efter sprintplaneringsmotet har vi en ny Scrum-tavla 
med nya uppgifter i kolumnen langst till vanster. Tekniskt sett ar detta 
sloseri men for erfarna Scrum-lag tar detta normalt inte sarskilt lang tid 
och rutinen att nollstalla tavlan kan ge en trevlig kansla av fullbordan och 
avslut. Lite som att diska efter middagen — att gora det ar en pina men det 
kanns bra efterat. 

I Kanban ar tavlan normalt en bestandig sak - du behover inte nollstalla 
den och borja om. 


Kanban: Varje dag 
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Scrum foreskriver 
_tvarfunktionella lag 

En Scrum-tavla ags av exakt ett lag. Ett Scrum-lag ar tvarfunktionellt, det 
bestar av alia de kompetenser som behovs for att fardigstalla alia 
uppgifter i sprinten. En Scrum-tavla ar vanligtvis synlig for den som ar 
intresserad men bara det agande Scrum-laget far andra i den - det ar deras 
verktyg for att hantera sitt atagande for pagaende iteration. 



I Kanban ar tvarfunktionella lag valfritt och tavlan behover inte agas av 
ett specifikt lag. En tavla relaterar till ett arbetsflode, inte nodvandigtvis 
ett lag. 
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Har ar tva exempel: 



Exempel 1: Hela tavlan betjanas av ett tvarfunktionellt lag. Precis som i 
Scrum. 



Exempel 2: Produktagaren satter prioriteringar i kolumn 1. Ett 
tvarfunktionellt lag utfor utveckling (kolumn 2) och test (kolumn 3). 
Leverans (kolumn 4) gors av specialistlag. Det finns ett litet overlapp av 
kompetenser sa om leveranslaget blir en flaskhals kan en av utvecklarna 
hjalpa dem. 

Sa i Kanban maste du etablera ett antal spelregler for vem som far 
anvanda tavlan och hur. Sedan experimenterar du med reglema for att 
optimera flodet. 
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Scrum-uppgifterna maste fa plats i en 
_sprint 

Bade Scrum och Kanban ar baserade pa inkrementell utveckling, dvs. att 
bryta ner arbetet i mindre delar. 

Ett Scrum-lag forbinder sig bara till de uppgifter som de tror att de kan 
klara av inom en iteration (baserat pa definitionen av ’’Klart”). Om en 
uppgift ar for stor for att fa plats i en sprint forsbker laget och 
produktagaren hitta satt att bryta ner den i mindre delar tills det far plats. 
Om uppgiftema tenderar att vara stora sa blir iterationema langre (men 
vanligtvis inte langre an 4 veckor). 


□ 


□ 


□ □ 



□ □ 

□□ 

□ □□ 



□ oo nn 

□ □□□ 

□ □□□□ 

□ □□□ 


Sprint 1 

Sprint 2 

Sprint 3 

Sprint 4 



Kanban-lag forsbker minimera ledtid och reglera flodet, vilket indirekt ger 
incitament att bryta ner uppgifter i relativt sma bitar. Men det finns ingen 
explicit regel som sager att uppgifter maste vara tillrackligt sma for att fa 
plats i en specifik tidslucka. Pa samma tavla kan vi ha en uppgift som tar 
1 manad att slutfora och en annan uppgift som tar 1 dag. 


PA- 


I Langvarig up 

pais 1 


grans - 

1 Langvarig uppgift 

□ 


= 3 

□ oo □□!□□□ 

!□□□ 

□ □□□ 
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Scrum foreskriver 
_estimering och hastighet 

I Scrum forvantas lagen uppskatta den relativa storleken (=mangd arbete) 
av vaije uppgift som de forbundit sig att utfora. Genom att summer a 
storlekarna av alia slutforda uppgifter vid slutet av sprinten far vi fram 
hastigheten. Hastigheten ar ett matt pa kapacitet - hur manga grejer vi kan 
leverera per sprint. Har ar ett exempel pa ett lag med en snitthastighet pa 
8 . 


H= 8 

H= 7 

H= 9 


□ □□ 

m 

nmm 


mi 3 i 

01 3 IE 

□□cm 0 


Sprint 1 

Sprint 2 

Sprint 3 



Sprint 2 Sprint 3 

9 0 0 


Att veta att snitthastigheten ar 8 ar trevligt eftersom vi da kan gora 
realistiska forutsagelser om vilka uppgifter vi kan slutfora i kommande 
sprintar och darmed kan vi gora realistiska leveransplaner. 

Kanban foreskriver inte estimering. Sa om du behover gora ataganden 
maste du bestamma hur du skapar forutsagbarhet. 

Vissa lag valjer att gora estimat och mata hastigheten precis som i Scrum. 
Andra lag valjer att hoppa over estimeringen men forsoker bryta ner alia 
uppgifter till ungefar lika stora delar. De kan sedan enkelt mata hastighet i 
termer av hur manga uppgifter som slutfors per tidsenhet (exempelvis 
funktioner per vecka). Somliga lag grupperar uppgifter i Minsta Saljbara 
Funktioner (MSF, engelska MMF) och mater genomsnittlig ledtid per 
MSF och anvander det for att etablera SLAer (Service Level Agreements) 
— till exempel ”nar vi atar oss en MSF levereras den alltid inom 15 dagar” 

Det finna alia mojliga intressanta tekniker for Kanban-massig 
leveransplanering och atagandehantering — men det foreskrivs inga 
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specifika tekniker sa Googla pa bara och prova nagra olika tekniker tills 
du hittar en som passar din situation. Vi kommer nog att se nagra ’’best 
practices” uppenbara sig med tiden. 




Bada tillater arbete pa flera 
_produkter samtidigt 

I Scrum ar “behovslista for produkt” ett ganska olyckligt namn eftersom 
det antyder att alia behov maste galla samma produkt. Har ar tva 
produkter, gron och gul, var och en med sin egen behovslista och sitt eget 
team: 


Produkt Produkt 

Gron Gul 



Om du bara har ett team da? Ja, tank mer pa behovslistan for produkten 
som en uppgiftslista for teamet. Den listar alia prioriteter for kommande 
iterationer for ett specifikt lag (eller uppsattning lag). Sa om laget 
underhaller flera produkter kombinerar du listorna till en. Det tvingar oss 
att prioritera mellan produkter vilket i vissa fall ar vardefullt. 

I praktiken kan man gora det har pa flera satt. En strategi kan vara att lata 
laget fokusera pa en produkt per sprint: 
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En annan strategi skulle kunna vara att lata laget arbeta pa funktioner fran 
bada produkter i vaije sprint. 


B 

I 


Samma sak galler Kanban. Yi kan lata flera produkter floda over samma 
tavla. Yi kan sarskilja dem med olikfargade kort: 






□ 

□ 

a 



.. .eller med “simbanor”: 



1 | | | 

Produkt Gron: 

nP R 
□ □□ 

Produkt Gul: 

B □ B 
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_ Bada ar slimmade och lattrorliga 

Jag tanker inte ga igenom ’’Lean Thinking” och det agila manifestet men 
generellt sett ar bade Scrum och Kanban val i linje med dess varderingar 
och principer. Exempelvis: 

• Scrum och Kanban ar bada sa kallade dragsystem for planering 
vilket motsvarar lagerhanteringsprincipen JIT (Just In Time) i 
Lean. Det betyder att laget valjer nar och hur manga uppgifter de 
forbinder sig att gora — de ”drar” arbete nar de ar fardiga snarare 
an att det ’’trycks” in utifran. Precis som en skrivare som drar in 
nasta sida forst nar den ar redo att skriva ut den (aven om det ar 
ett litet och begransat parti papper som den kan dra ifran). 

• Scrum och Kanban ar baserade pa kontinuerlig och empirisk 
processoptimering vilket motsvarar Kaizen-principen i Lean. 

• Scrum och Kanban betonar respons pa forandringar framfor att 
folja en plan (aven om Kanban typiskt medger snabbare respons 
an Scrum), vilket ar ett av de fyra vardena i det agila manifestet. 

... och sa vidare. 

Fran ett perspektiv kan Scrum ses som ganska oslimmat eftersom det 
foreskriver satsvis bearbetning i tidsbegransade iterationer. Men det beror 
pa iterationslangden och vad man jamfor med. Jamfort med en mer 
tradition ell process dar man kanske integrerar och levererar 2-4 ganger 
per ar sa ar ett Scrum-lag som producerar leveransfardig kod varannan 
vecka extremt slimmat. 

Men om du sedan fortsatter att gora iterationema kortare och kortare 
narmar du dig egentligen Kanban. Och nar du borjar fundera pa att gora 
iterationema kortare an 1 vecka skulle du kunna overvaga att skippa 
tidsbegransade iterationer helt och hallet. 

Jag har sagt det forut och jag sager det igen: experimentera tills du hittar 
ett satt som fungerar! Och fortsatt sedan att exeperimentera :o) 
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Mindre skillnader 

Har ar nagra skillnader som forefaller mindre betydelsefulla jamfort med 
dem som redan namnts. Det kan dock vara bra att kanna till dem. 

Scrum foreskriver en prioriterad 
behovslista for produkten 


I Scrum utfors alltid prioritering genom att sortera behovslistan for 
produkten och andringarna trader i kraft till nasta sprint (inte i den 
pagaende). I Kanban kan du valja godtyckligt prioriterings system (eller 
inget alls) och andringarna trader i kraft sa snart det finns tillganglig 
kapacitet (snarare an vid bestamda tider). Det kanske finns eller inte finns 
en behovslista for produkten och den kan vara eller ar inte prioriterad. 

I praktiken spelar det har mindre roll. Pa en Kanban-tavla fyller den 
vanstra kolumnen vanligtvis samma syfte som behovslistan i Scrum. 
Oavsett om listan ar sorterad efter prioritet eller inte sa maste laget ha 
nagon slags beslutsregel for vilken uppgift som ska tas forst. Nagra 
exempel pa sadana beslutsregler: 

• Ta alltid den oversta uppgiften. 

• Ta alltid den aldsta uppgiften (varje uppgift har alltsa en 
tidsstampel). 

• Ta vilken uppgift som heist. 

• Spendera runt 20% av tiden pa uppgifter som ror underhall och 
80% pa uppgifter som ror ny funktionalitet. 

• Dela upp lagets kapacitet ungefar jamnt mellan produkt A och 
produkt B. 

• Ta alltid roda uppgifter forst — om det finns nagra. 
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I Scram kan behovslistan for produkten ocksa anvandas mer Kanban- 
aktigt. Yi kan begransa dess storlek och skapa beslutsregler for hur den 
ska prioriteras. 

I Scrum foreskrivs dagliga moten 


Ett Scrum-lag har korta moten (hogst 15 minuter) vaije dag vid samma tid 
och samma plats. Syftet med motena ar att sprida information om vad som 
pagar, att planera dagens arbete och att identifiera betydande problem. Det 
kallas ibland for dagliga sta-upp-moten eftersom de vanligtvis halls 
staende (for att halla det kort och for att bihalla en hog energiniva). 

Dagliga sta-upp-moten foreskrivs inte i Kanban men de fiesta Kanban-lag 
verkar gora det i alia fall. Det ar en suveran teknik oavsett vilken process 
du anvander. 

I Scram ar motets format personorienterat — varje person rapporterar, en 
efter en. Manga Kanban-lag anvander ett mer tavel-orienterat format med 
fokus pa flaskhalsar och andra synliga problem. Den ansatsen ar mer 
skalbar. Om du har 4 lag som delar samma tavla och som kor sina dagliga 
sta-upp-moten tillsammans sa behover vi inte nodvandigvis sta och lyssna 
pa var och en sarskilt lange eftersom vi fokuserar pa flaskhalsarna som 
syns pa tavlan. 

I Scrum foreskrivs progressdiagram 


Progressdiagrammet for 
sprinten visar, pa daglig 
basis, hur mycket arbete som 
aterstar i den pagaende 
iterationen. 

Y-axelns enhet ar densamma 
som for uppgiftema. Typiskt 
ar det timmar eller dagar (om 
laget bryter ner uppgiftema 
till aktiviteter) eller 
’’historiepoang” (om de inte gor det). Det firms dock manga olika 
varianter av det har. 

I Scram anvands sprintens progressdiagram som ett av de viktigaste 
verktygen for att bevaka framsteg i en iteration. 
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Nagra lag anvander ocksa progressdiagram for leveranser vilket foljer 
samma format men pa leveransniva - det visar vanligtvis hur manga 
historiepoang som aterstar i behovslistan for produkten efter vaije sprint. 

Huvudsyftet med ett progressdiagram ar att pa ett enkelt satt och sa tidigt 
som mojligt ta reda pa om vi ligger efter eller fore i planen sa att vi kan 
anpassa oss darefter. 

I Kanban foreskrivs inte nagra progressdiagram. Faktum ar att det inte 
foreskrivs nagot sarskilt diagram alls. Men du far naturligtvis anvanda 
vilket diagram du vill (inklusive progressdiagram). 

Har ar ett exempel pa ett kumulativt flbdesdiagram. Den har typen av 
diagram illustrerar pa ett trevligt satt hur jamnt ditt flbde ar och hur PA- 
granserna paverkar ledtiden. 



□ Behovslista 

■ Utveckling 

■ Test 

■ Produktion 


Sa har funkar det. Varje dag summeras antalet uppgifter i respektive 
kolumn pa Kanban-tavlan och vardena staplas ovanpa varandra utmed Y- 
axeln. Sa pa dag 4 fanns det 9 uppgifter pa tavlan. Med boijan pa den 
hogersta kolumnen sa fanns det 1 uppgift i Produktion, 1 uppgift i Test, 2 
uppgifter i Utveckling och 5 uppgifter i Behovslistan. Om vi plottar dessa 
punkter varje dag och binder samman punkterna sa far vi ett lika fint 
diagram som ovan. De vertikala och hortisontella pilarna illustrerar 
relationen mellan PA och ledtid. 

Den horisontella pilen visar att uppgifter som lades till behovslistan pa 
dag 4 i snitt tog 6 dagar att na produktion. Omkring halften av tiden var i 
Test. Yi kan se att om vi begransade PA i Test och Behovshsta skulle vi 
avsevart minska den totala ledtiden. 
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Lutningen pa den morkbla ytan visar hastigheten (dvs. antalet uppgifter 
som driftsatts per dag). Over tiden kan vi se hur hogre hastighet minskar 
ledtiden medan hogre PA okar ledtiden. 

De fiesta organisationer vill fa saker gjort snabbare (=minska ledtiden). 
Olyckligtvis trillar manga i fallan att anta att det betyder fler personer 
eller att fler ska arbeta overtid. Det mest effektiva sattet att fa saker gjort 
snabbare ar oftast att jamna ut flodet och begransa arbetet till tillganglig 
kapacitet, inte att lagga till fler manniskor eller att arbeta hardare. Den har 
typen av diagram visar varfor och okar darmed sannolikheten for att laget 
och ledningen samarbetar mer effektivt. 

Det har blir annu tydligare om vi skiljer pa kotillstand (som att ’’vanta pa 
test”) och arbetstillstand (som att ’’testa”). Vi vill definitivt minimera 
antalet uppgifter som star och vantar pa ko och det kumulativa 
flodesdiagrammet hjalper oss att hitta ratt incitament for det. 
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Scrum-tavla vs. Kanban-tavla 
_- ett mindre trivialt exempel 

I Scrum ar uppgiftslistan for sprinten bara en del av helheten — den del 
som visar vad laget gor i den pagaende sprinten. Den andra delen ar 
behovslistan for produkten — listan over saker som produktagaren vill fa 
gjort i kommande sprintar. 

Produktagaren far se men inte rora uppgiftslistan for sprinten. Hon kan 
gora forandringar i behovslistan for produkten nar hon vill men 
andringarna trader inte i kraft (dvs. andringar av vilket arbete som blir 
gjort) forran till nasta sprint. 



Nar sprinten ar fardig kan laget “leverera potentiellt levererbar kod” till 
produktagaren. Laget avslutar sprinten, genomfor en sprintgranskning och 
demonstrerar stolt funktionema A, B, C och D for produktagaren. 
Produktagaren kan nu besluta om detta ska levereras eller inte. Den sista 
delen — att faktiskt leverera produkten — ingar vanligtvis inte i sprinten 
och ar darfor inte synligt i uppgiftslistan for sprinten. 
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I samma scenario kan en Kanban-tavla istallet se ut sa har: 


Behov 

Utvalt 

2 

Utvi 

Pagaende 

eckling 

3 

Klart 

Driftas 

Live! 

i 1 #? 1 

nrm 

m 

m 

\m 

ra 


& 


Nu ar hela arbetsflodet pa samma tavla - vi tittar inte bara pa vad ett 
Scrum-lag gor i en iteration. 

I exemplet ovan ar “Behov”-kolumnen bara en generell onskelista utan 
sarskild ordning. ”Utvalt”-kolumnen innehaller de hogprioriterade 
behoven och har en Kanban-grans pa 2. Det far alltsa bara Annas 2 
hogprioriterade uppgifter vid varje givet ogonblick. Sa fort laget ar redo 
att borja pa en ny uppgift tar de den oversta uppgiften fran ’’Utvalt”. 
Produktagaren kan gora andringar i ’’Behov”- och ”Utvalt”-kolumnema 
nar han vill men inte i de andra kolumnerna. 

”Utveckling”-kolumnen (indelad i tva underkolumner) visar vad som for 
narvarande utvecklas och den har en Kanban-grans pa 3.1 natverkstermer 
motsvarar Kanban-gransen ’’bandbredd” och ledtiden motsvarar ’’pingtid” 
(eller svarstid). 

Varfor har vi delat in ”Utveckling”-kolumnen i de tva underkolumnema 
’’Pagaende” och ’’Klart”? Jo, for att ge driftsattningslaget en mojlighet att 
veta vilka uppgifter som de kan boija driftsatta. 

Gransen 3 for “Utveckling” delas mellan de tva underkolumnema. Varfor 
da? Anta att det firms 2 uppgifter i ’’Klart”: 


Utveckling 


w i vcurNimy 

3 

Pagaende 

Klart 

□□ 
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m 
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Det betyder att det bara far Annas 1 uppgift i “Pagaende”. Det betyder att 
det kommer att finnas overskottskapacitet — utvecklare som skulle kunna 
boija pa en ny uppgift men som inte far det pa grand av Kanban-gransen. 
De ger dem ett starkt incitament att fokusera sin kraft pa att hjalpa till att 
fa saker i drift, rensa ”Klart”-kolumnen och maximera flodet. Den har 
effekten ar trevlig och gradvis - ju mer saker den finns i ’’Klart” desto 
mindre saker tillats i ’’Pagaende” vilket hjalper laget att fokusera pa ratt 
saker. 

Enuppgiftsflode 

Enuppgiftsflodet ar ett slags “perfekt flbde”-scenario dar vaije uppgift 
flyter over tavlan utan att fastna i nagon kb. Det betyder att i vaije 
ogonblick finns det nagon som arbetar pa uppgiften. Sa har kan tavlan se 
ut i en sadan situation: 


Behov 

Utvalt 

2 

Utveckling 

3 

I produktion :o) 

Pagaende 

Klart 





& 


Just nu sa utvecklas B samtidigt som A driftssatts. Sa fort laget ar redo for 
nasta uppgift fragar de produktagaren vad som ar viktigast och far 
omedelbart svar. Om det har ideala scenariot fortsatter kan vi skrota de 
tva koema ’’Behov” och ’’Utvalt” och uppna riktigt kort ledtid. 

Corey Ladas (forfattare till ’’Scrumban”, overs, anm.) har formulerat det 
val: ”Den ideala planeringsprocessen ska alltid forse utvecklingslaget med 
det basta att arbeta pa harnast, varken mer eller mindre”' 

PA-gransema anvands for att forhindra att problem gar overstyr, sa om 
allt flyter pa anvands faktiskt inte PA-gransema. 
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En dag i Kanban-land 
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Maste Kanban-tavlan se ut sa har? 

Nej, tavlan ovan ar bara ett exempel! 

Det enda som Kanban foreskriver ar att arbetsflodet bor vara synligt och 
att PA-granser bor sattas. Syftet ar att skapa ett jamnt flode genom 
systemet och att minimera ledtiden. Du maste regelbundet ta upp fragor 
som: 

Vilka kolumner bor vi ha? 

Varje kolumn representerar ett tillstand i arbetsflodet eller en ko (buffert) 
mellan tva tillstand. Borja enkelt och lagg till kolumner vid behov. 

Vad bor Kanban-granserna vara? 

Nar Kanban-gransen for ”din” kolumn natts och du inte har nagot att gora 
sa kan du borja titta ’’nerstrom” (alltsa pa uppgifter som tomar upp till 
hoger pa tavlan) och hjalpa till att atgarda flaskhalsar. Om det inte finns 
nagra flaskhalsar ar det en indikation pa att Kanban-gransen kan vara for 
lag eftersom syftet med gransen var att minska risken att mata pa och 
skapa flaskhalsar nerstroms. 

Om du upptacker att for manga uppgifter star stilla under langre tid utan 
att bli arbetade pa ar det en indikation pa att Kanban-gransen kan vara for 
hog. 


• For lag Kanban-grans => inaktiva manniskor => lag produktivitet 

• For hog Kanban-grans => inaktiva uppgifter => lang ledtid 

Hur stranga ar Kanban-granserna? 

Vissa lag ser dem harda (dvs. laget far inte overskrida en grans). Andra 
lag ser dem som riktlinjer och diskussionsstartare (dvs. att bryta en grans 
ar tillatet men det ska vara ett medvetet beslut med ett konkret syfte). Sa, 
aterigen, det ar upp till dig. Visst sa jag att Kanban inte var sarskilt 
foreskrivande? 
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Sammanfattning av Scrum vs. Kanban 

Likheter 

• Bada ar Lean och Agila 

• Bada anvander ’’dragplanering” (se kapitel 13). 

• Bada begransar PA. 

• Bada anvander transparens for att driva processforbattringar 

• Bada fokuserar pa att leverera levererbar programvara tidigt och 
ofta. 

• Bada baseras pa sjalvorganiserande lag 

• Bada kraver att arbete bryts ner i bitar 

• I bada optimeras leveransplanen kontinuerligt baserat pa 
empiriska data (hastighet / ledtid) 
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Skillnader 


Scrum 

Kanban 

Foreskriver tidsbegransade 
iterationer. 

Tidsbegransade iterationer ar 
valfritt. Kan ha olika rytmer for 
planering, leverans och process- 
forbattring. Kan vara handelse- 
styrt istallet for tidsbegransat. 

Laget forbinder sig till en viss 
mangd arbete for iterationen. 

Atagande ar valfritt. 

Anvander hastighet som ett 
standardmatt for planering och 
processforbattring. 

Anvander ledtid som 
standardmatt for planering och 
proce s sforbattring. 

Foreskriver tvarfunktionella lag 

Tvarfunktionella lag ar valfritt. 

Specialistlag tillatna. 

Uppgifter maste brytas mer sa 

att de kan slutforas inom 1 sprint. 

Ingen sarskild uppgiftsstorlek 
foreskrivs. 

Foreskriver progressdiagram 

Ingen sarskild sorts diagram 
foreskrivs. 

PA begransas indirekt (per 
sprint) 

PA begransas explicit (per 
tillstand i arbetsflodet) 

Foreskriver estimering 

Estimering ar valfritt 

Uppgifter kan laggas till 
pagaende iteration 

Uppgifter kan laggas till sa fort 
det finns tillganglig kapacitet. 

En uppgiftslista for sprinten ags 
av ett specifikt lag 

En Kanban-tavla kan delas av 
flera lag eller individer. 

Foreskriver 3 roller 

(PA/SM/Lag) 

Foreskriver inga roller 

En Scrum-tavla rensas mellan 
varje sprint 

En Kanban-tavla ar bestandig 

Foreskriver en prioriterad 
behovslista for produkten. 

Prioritering ar valfritt 


















Sammanfattning av Scrum vs. Kanban 153 


Sadar. Det var det, det. Nu vet du vad skillnadema ar. 

Men det ar inte slut an! Nu ar det dags for den basta delen! Ta pa 
stovlama for nu ar det dags att hoppa ner i skyttegraven med Mattias och 
se hur det har ter sig i praktiken! 




Del II - Fallstudie 


Kanban i verkliga livet 




Det liar dr historien om hur vi larde oss forbattring genom Kanban. Nar 
vi borjade fanns det inte mycket information tillganglig och Dr Google 
lamnade oss for en gangs skull tomhanta. Idag utvecklas Kanban 
framgangsrikt och det finns en vdxande kunskap tillganglig. Jag kan 
varmt rekommendera att ta en titt pa David Andersons arbete, exempelvis 
rorande ’classes of service’. Sa heir kommer den forsta (och sista) 
friskrivningen (jag lovar!). Vilka losningar du an genomfor, se till att de 
adresserar de specifika problemen. Sddar, klart. Lat oss kora igang. Det 
har dr var berattelse. 

/Mattias Skarin 
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_ Driftavdelningens natur 

On du nagonsin varit pa jour 24/7 sa har du en god uppfattning om hur det 
kanns att ansvara for en produktionsmiljo. Du forvantas reda ut problem 
mitt i natten oavsett om du ar kalian till problemet eller ej. Ingen vet vad 
felet ar, det ar darfor de ringer dig. Det ar en ratt stor utmaning eftersom 
du inte byggde hardvaran, drivrutinerna, operativsystemet eller den 
anpassade programvaran. Dina mojlighter ar ofta begransade till att 
begransa effekten, spara bevis for att aterskapa problemet och att vanta pa 
den person som ar ansvarig for att orsakat besvaren sa att denna kan 
reproducera och losa problemet som du just bevittnat. 

For driftavdelningen ar hastighet och nogrannhet i bade svarstider och 
problemlosning viktiga. 


57 




18 

_ Drivkraft till forandring 

2008 genomforde en av vara kunder, ett skandinaviskt spelutvecklings- 
foretag, en mangd processforbattringar. En av dessa forbattringar innebar 
uppskalning av Scrum till hela utvecklingsavdelningen samt en successiv 
eliminering av hinder som forhindrade utvecklingsteamen att leverera 
programvara. Nar programvaran boijade floda och kapaciteten okade, 
okade ocksa trycket pa driftavdelning. Tidigare hade IT-teknikerna mest 
statt och sett pa fran hall - nu blev de alltmer involverade som en aktiv 
part i utvecklingsprocessen. 


r 


Databas- 

administratorer 


Driftavdelning 


System- 

administratorer 


1 


Second line 
support 


Figur 1. Foretagets driftavdelning omfattade tre team: data- 
basadministratorer, systemadministratorer och second line support. 

En konsekvens av detta var att det inte rackte med att hjalpa 
utvecklingsteamen. Om man fortsatte att uteslutande fokusera pa att 
hjalpa utvecklingsteamen skulle det orsaka forseningar i det kritiska 
forbattringsarbetet av infrastrukturesom leddes av driftavdelningen. Det 
behovdes forbattringar pa bada omraden. 

Dessutom ledde framstegen pa utvecklingssidan till att chefema 
efterfragades alltmer for hjalp med analys och aterkoppling av ideer i 
tidiga projektstadier. Det betydde i sin tur att de tick mindre tid over till 
lopande prioritering och problemlosning. Ledningsgruppen insag att de 
maste agera innan situationen blev ohanterlig. 
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Var borjar vi? 

En bra boijan var att fraga utvecklingsteamet, dvs. driftavdelningens 
kund. 


Utvecklings syn pa driftavdelningen 


Jag stallde fragan “vilka ar de tre viktigaste sakerna du kommer att tanka 
pa vad galler ’IT-drift’? De vanligaste svaren var: 

"Varierande kompetens ” “Supportsystemet suger ’’ 

“Mycket kompetenta i IT- “Vad halier de pa med? ” 

infrastruktur” 

“De vill hjalpa till menfaktum dr “Det behovs manga e-mail 

att det dr svart att fa hjalp. ” for enkla saker ” 

“Projekten tar for lang tid” “Svara att kontakta ’’ 

I korthet var detta utvecklingsteamets syn pa driftavdelningen. Lat oss nu 
jamfora med vad driftavdelningen tyckte om utveckling... 

Driftavdelningens syn pa utveckling 
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“Varfor anvdnder ni inte fordelarna med den befmtliga plattformen? ” 
“Lat oss gora releasehanteringen mindre tungrodd!” 

“Vi lider av er daliga kvalitet! ” 

“De borde andra pa sig” var ett aterkommande tema i argumenten fran 
bada sidor. For att losa de gemensamma problemen skulle vi 
uppenbarligen behova andra det synsattet. Pa pluskontot fanns gott 
fortroende for kamkompetensen (’’mycket kompetenta i IT-infrastruktur”) 
vilket fick mig att tro att ”vi och dom”-mentaliteten skulle kunna rattas 
till om vi bara skapade ratt forhallanden. 




Satta igang 


Sa vi behovde satta igang. Men var skulle vi boija? 

Jag hade en bakgrand som programmerare sa jag visste verkligen lite om 
IT-drift. Jag tankte inte ’’storma in och andra pa saker”. Jag behovde en 
mindre konfronterande ansats som alltjamt skulle lara oss de viktiga 
sakema, forkasta de irrelevanta sakerna och vara latt att lara. 

Kandidaterna var: 

1. Scrum — detta fungerade bra i utvecklingslagen 

2. Kanban — nytt och oprovat men med en bra passform till Lean- 
principerna som vi saknade. 

Yid diskussion med chefema verkade Kanban och Lean-principema 
kunna tackla de problem som vi forsokte adressera. Fran deras perspektiv 
skulle inte sprintar passa sarskilt bra eftersom man omprioriterade 
dagligen. Darfor var Kanban en logisk startpunkt aven om det var nytt for 
oss alia. 
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_ Kora igang teamen 

Hur skulle vi kora igang teamen? Det fanns ingen tillganglig handbok i 
hur man kor igang. Om vi gjorde fel skulle det innebara stora risker. 
Forutom att ga miste om forbattringarna skulle vi hantera en 
produktionsplattform med synnerligen specialiserade och skickbga 
utvecklare som var svara att ersatta. Att fjarma dem skulle vara en daaalig 
ide. 


• Skulle vi bara satta igang och hantera konsekvensema allt 
eftersom de uppstod? 

• Eller skulle vi kora en workshop forst? 

For oss var det uppenbart - vi skulle forst kora en workshop. Men hur? 
Det var en utmaning att fa hela driftavdelningen att delta i en workshop 
(vem svarar da om nagon ringer?). Till slut bestamde vi oss for att 
genomfora en halvdags-workshop och att halla den enkel och 
ovningsbaserad. 


Workshopen 


En av fordelama med en workshop var att det tidigt skulle blottlagga vara 
problem. Det bidrog ocksa till att skapa en fortroendeingivande miljo i 
vilken implikationer kunde diskuteras direkt med deltagarna. Arligt talat - 
alia var inte overdrivet entusiastiska over att andra arbetssatt. De fiesta var 
dock oppna for att prova. Sa vi genomforde en workshop dar vi 
demonstrerade de viktigaste principerna och korde en nerskalad Kanban- 
simulering. 
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i grundlaggande principer 


• Begransa arbete efter kapacitet. 


• 3 "arbetstyper"; 

• Batchstorlek vs. cykeltid. 


besvara fragor, 
bygg en Lego-bil, 

Designa och bygg ett hus. 

• Pagaende arbete vs. genomstromning. 


• 3 iterationer 

• Restriktionsteori. 


Mat hastighet per arbetstyp. 
Experimentera, justera PA. 



• Avrapportera. 


I slutet av workshopen gjorde vi en “femfmger”-rostning for att 
kontrollera om teamen var villiga att prova det har i verkligheten. Inga 
invandningar framkom sa vi beslot att satta igang. (Femfingerrostning dr en 
konsensusskapande metod ddr varje deltagare indikerar sin enighet pa en skala 
fran 1 till 5 fingrar. 5 betyder stdrst enighet, 1 betyder mest oenig, 3 betyder 
enighet med reservation. Konsensus har uppnatts nar varje deltagare i gruppen 
halier upp minst 3 fingrar.) 
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Adressera intressenter 

Personer beroende av driftavdelningens jobb (aven kallat ’’stekhallare”) 
skulle sannolikt bli paverkade av introduktionen av Kanban. Visserligen 
var forandringama till det battre — det skulle innebara att laget boijade 
saga ”nej” till arbete som de inte skulle kunna slutfora, sta upp for kvalitet 
och ta bort lagprioriterade uppgifter fran lagets uppgiftslista. Trots detta ar 
det alltid en bra ide att forst ha en dialog. 

De narmsta intressentema var “first-line support” och avdelningschefema. 
Eftersom de hade deltagit i workshopen sa var de reda positivt installda 
till att ga vidare. Samma sak gallde utvecklingsteamen (som mer eller 
mindre anda forvantade sig forbattringar). Men for ett team som support, 
var saken en annan. Deras mest signifikanta problem var att de var 
overbelastade. Dessutom hanterade de alia kundarenden och foretaget 
hade atagit sig att svara pa alia arenden. Detta skulle sannolikt forandras 
om vi introducerade Kanban och borjade tvinga fram begransningar pa 
pagaende arbete - PA (work in progress, ”W1P” pa engelska/or/ anm.). 

Sa vi hade ett mote med de viktigaste intressentema dar vi presenterade 
var intention, forvantade fordelar och mojliga konsekvenser. Till min 
lattnad togs vara ideer generellt sett val emot, ibland med kommentaren 
’’utmarkt om vi antligen kan hantera de har sakema en gang for alia”. 
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Hur vi skapade den forsta tavlan 

En bra start for att skapa en Kanban-tavla ar att kartlagga vardeflodet. Det 
ar i grand och botten en visualisering av vardekedjan och ger en insikt i 
arbetstillstand, flode och tid genom systemet (cykeltid). 


I Defekt 

| hittad 


H Ring och 
rapportera 


Vanta i telefonko 

5 min 


Vanta pS Sterskapande 


po a 


]— 


Vanta p§ utvecklare Vanta p§ release 

Reiease I 

2 dagar 1/2 dag 

1 manad 2 veckor 


Vardeskapande tid (3,6 d) 
Total tid (33 d) 


11 % 


Men vi boijade mycket enklare: ett forslag ritat pa papper tillsammans 
med chefen. Granskad ett antal ganger och sedan korde vi igang. Fragor 
som togs upp under denna fas var bland andra: 

• Vilka typer av arbete har vi? 

• Vem hanterar det? 

• Ska vi dela ansvar for olika arbetstyper? 

• Hur hanterar vi delat ansvar nar vi har specialiserade kunskaper? 

Eftersom de olika arbetstypema hade overenskomna servicenivaer (SLA) 
kandes det naturligt att lata varje lag styra utformningen av sin egen tavla. 
De tog fram kolumner och rader sjalva. 

Nasta stora beslut var huravida ansvar skulle delas for olika arbetstyper. 
’’Skulle vi lata en fast del av teamet hantera direkta fragor (reaktivt arbete) 
och lata resten av laget fokusera pa projekten (proaktivt arbete)?” Vi 
bestamde oss forst for att prova delat ansvar. En nyckelorsak till det var 
att vi hade identifierat att sjalvorganiserande lag och forts att larande och 
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kunskapsbverfbring bland lagdeltagarna var nodvandigt for att sakerstalla 
tillvaxt. Nackdelen med beslutet var de potentiella avbrott alia kunde 
drabbas av men det var den basta losningen vi kunde komma fram till fran 
boijan. En liten notering: nar vi korde workshopen sa sjalvorganiserade 
sig faktiskt lagen kring detta problem. De lat en person hantera de 
omedelbara forfragningama och resten hantera de storre arendena. 

Den forsta Kanban-modellen 


Nedan visas den grundlaggande modellen som vi anvande for Kanban. 
Notera att laget valde att lata uppgifter floda uppat (som vattenbubblor) 
istallet for att folja den mer typiska modellen med flode fran vanster till 
hoger. 


Forslag till Kanban-tavla 


Prioriteter^ 



Figur 2. Den forsta modellen av Kanban-tavlan. Prioriteter gar fran 
vanster till hoger, flodet gar uppat. PA raknas som det totala antalet 
uppgifter i ’’Pagaende arbete”-raden (inringat). Modellen ar 
inspirerad av erfarenheter som rapporterats av Linda Cook. 
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Figur 3. Den forsta Kanban-tavlan for systemadministrationsteamet. 
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Rader 


Arbetsflodestillstand 

Sa definierade vi det 

Behovslista 

Anvandarberattelser (’’user stories”) 
som chefen beslutade att man 
behover. 

Redo for arbete 

Anvandarberattelser som ar 

estimerade och nedbrutna till 
uppgifter pa vardera max 8 timmar. 

Pagaende arbete 

Raden med PA-gransen. Vi borjade 
med en grans pa 2 x lagstorleken - 1 
(-1 ar for samarbete). Ett 5- 
personerslag har alltsa en PA-grans 
pa 7. 

Klart 

Korbart av slutanvandaren. 


Kolumner 


Arbetstyp 

Sa definierade vi det 

Leverans (Release) 

Hjalpa utvecklingsteam att leverera 
programvara. 

Support 

Mindre forfragningar fran andra lag. 

Oplanerat (Unplanned) 

Ovantat arbete som maste goras men 
som inte har en tydlig agare. 
Exempelvis mindre forbattringar I 
infrastruktur. 

Project A 

Storre drifthanteringsprojekt. 

Exempelvis att byta hardvaran i en 
stagingmiljb. 

Project B 

Ett annat stort projekt. 


Alla Kanban-tavlor sag inte likadana ut. Vi boijade med en enkel skiss 
som utvecklades allt eftersom. 
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Att satta den forsta gransen 
_for pagaende arbete (PA) 

Var forsta grans for produkter i arbete var ratt generos. Yi resonerade att 
genom att visualisera flodet sa skulle vi se och uppleva vad som pagick 
samt att det var osannolikt att vi skulle lyckas gissa den basta gransen fran 
boijan. Med tiden justerade vi PA-gransen sa fort vi fann en god 
anledning att gora det. Den forsta PA-gransen sattes till 2n-l (n=antal 
lagspelare, -1 for att uppmuntra samarbeta). Varfor? Enkelt. Yi hade 
ingen battre ide ©. Dessutom verkade det okontroversiellt for att komma 
igang. Formeln erbjod en enkel och logisk forklaring till alia som forsokte 
tvinga pa laget mer arbete: ”...sa anta att varje teammedlem kan arbeta pa 
hogst tva saker samtidigt, en aktiv och en vantande, hur kan vi forvanta 
oss att de ska kunna ta sig an meraT. Nar jag ser tillbaka pa inser jag att 
vilken generos grans som heist skulle gatt bra att borja med. Genom att 
bevaka Kanban-tavlan ar det enkelt att hitta de ratta gransema allt 
eftersom. 


Support 

(y-107 

IfLACT 

PeoiE^r Alfa 
( y-12/ 

Pcoffitr faMo 
(i*o 

Peoteet Theta 


Test ^20 j 

Sep^ee 


PSgSende 
arbete begransaty 


HC«ETE<^JSlClNUPj 

[j«J 

Client J 



Ceoo Cmt j 

PecftstJ 




Uppqiftec 

s 

PEPFTgrj 

fTJ 








Figur 4. Hur vi applicerade granserna for pagaende arbete for DBA- 
och systemadministrations-lagen. En grans for varje arbetstyp. 
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En observation vi gjorde var att det var meningslost att definiera PA- 
granser i anvandarberattelsepoang (’’story points”). Det var helt enkelt 
alldeles for svart att halla koll pa. Den enda gransen som var latt nog att 
halla koll pa var helt enkelt att rakna antalet uppgifter (= parallella 
uppgifter). 

For supportteamet anvande vi PA-granser definierat per arbetstyp 
(kolumn) eftersom vi behovde snabbare reaktion om gransen overtraddes. 
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Hur vi larde oss respektera produkter i 
_arbete 

I teorin later det enkelt att respektera PA-granserna men i praktiken ar det 
en utmaning. Det innebar namligen att i nagot skede saga ”nej”. Vi har 
provat olika ansatser for att hantera detta. 

Diskutera framfor tavlan 


Om en overtradelse upptacktes forde vi samman intressentema framfor 
tavlan och fragade vad de ville uppna. I borjan berodde overtradelser 
oftast pa oerfarenhet. I vissa fall identifierade vi olika syn pa 
prioriteringen dar ett typiskt fall utgjordes av lagspelare som var specialist 
inom ett specifikt omrade. Det var de enda gangema som vi upplevde 
nagon friktion. I merparten av fallen reddes problemen ut dar och da 
genom att diskutera framfor tavlan. 

Skapandet av en oversvamningssektion 


I fallet med supportteamet hade vi ett dilemma med att infora PA-granser. 
Enligt regiering pa marknaden var de tvunga att lova svara pa alia fragor, 
sa det var svart att saga nej till vissa fragor. Det var helt enkelt for 
konfronterande att saga ”nej”. Vi loste det genom att infora en 
oversvamningssektion som tradde i kraft sa snart PA-gransen overtraddes. 
Tva regler gallde for att fa flytta uppgifter till oversvamningssektionen: 

1. En kontakt tas med behovsstallaren. Vi informerade om att vi inte 
glomt bort arendet men att vi inte kunda ta det just nu, so fort det 
fanns ledig tid sklle vi gora det. Vi foreslog aven att om det fanns 
en alternativ losning vore det klokt att bruka den 

2. Om vi tar bort uppgiften sa blir du informerad om det. 

Efter tva veckor var det uppenbart att de oversvammade uppgifterna 
troligtvis aldrig skulle hanteras sa med stod fran chefen plockade vi bort 
dem fran tavlan. 
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Figur 5. En skiss over Kanban-tavlan for supportlaget. 
Oversvamningssektionen ar langst till hoger. 











_ Vilka uppgifter hamnar pa tavlan? 

Vi bestamde tidigt att inte ta alia typer av arbete som teamet utfor skulle 
hamna pa tavlan. Att bevaka saker som telefonsamtal eller hamta kaffe 
skulle gora Kanban till ett administrativt monster. Vi var har for att losa 
problem, inte skapa dem ©. Sa vi bestamde att endast satta upp uppgifter 
med en storlek >1 timme pa tablan och allt darunder betraktade vi som 
”vitt brus”. 1-timmesgransen fungerade faktiskt ratt bra och var en av de 
saker som forblev oforandrade. (Vi var tvungna att revidera vara 
antaganden om vilken paverkan bakgrundsbruset skulle ha men mer om 
det senare). 


Total 

kapactitet 



I Genomsnittlig kapacitet 
for att hantera 
supportarenden 


Figur 6. Vi borjade med att anta att den totala kapaciteten framst 
konsumerades av tva arbetstyper, storre (projekt) och mindre 
(support). Genom att halla reda pa hastigheten for projekt kunde vi 
fa en indikation pa leveransdatum om det behovdes. ”Vitt brus” 
(mindre support <1 timme, moten, hamta kaffe, hjalpa kolleger) 
forvantade vi alltid skulle finnas. 
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_ Hur estimera? 

Det finns flera altemativ och det finns sannerligen mer an ett svar: 

• Estimera regelbundet 

• Estimera nar det finns ett behov 

• Anvand ideala dagar/anvandarberattelsepoang som estimat 

• Estimat ar osakra, anvand nagot enkelt, tex. T-trojestorlekar 
(Liten, Medium, Stor) 

• Estimera inte eller estimera bara nar det finns en 
fbrdrojningskostnad som motiverar det. 

Nagot influerade av Scrum (eftersom det trots allt var darifran vi kom) 
bestamde vi oss att borja med historiepoang. Men i praktiken behandlade 
teamet anvandarberattelsepoang som om de vore ekvivalenta med 
mantimmar (det kandes mer naturligt). I borjan estimerade vi alia 
anvandarberattelser. Med tiden larde sig chefema att om de holl nere 
antalet pagaende projekt sa skulle de inte tvinga intressenterna vanta. De 
larde sig ocksa att om det uppstod en plotslig forandring sa kunde de 
prioritera om och adressera problemet. 

Nar vi insag att vi oftast levererade vara delar av projekt innan andra 
behovde dem minskade behovet av estimerimg. Detta ledde till att chefer 
slutade fraga efter tidiga estimat. De gjorde endast det om de var oroliga 
for att de skulle tvinga nagon vanta langre an vantat. 

I ett tidigt skede, stressad av ett telefonsamtal, lovade en chef 
projektleverans "i slutet av denna veckan”. Da projektet fanns pa 
Kanban-tavlan var det enkelt att estimera framstegen (genom att rakna % 
fordigt arbete) och dra slutsatsen att ungefar 25% var klart efter en 
vecka). Alltsa kravdes ytterligare tre veckor. Konfronterad med fakta 
andrade chefen projektets prioritet, stoppade parallellt arbete och gjorde 
leveransen mojlig. Kolia alltid med tavlan. © 
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Vad betyder estimerad storlek? Ledtid eller 
arbetstid? 


Vara anvandarberattelsepoang representerade arbetstid, dvs. hur manga 
timmar oavbrutet arbete som vi forvantade oss att anvandarberattelsen 
skulle ta. Inte ledtid (eller kalendertid; eller antal timmars vantetid). 
Genom att mata antalet anvandarberattelsepoang som nadde ’’klart” varje 
vecka (hastighet) sa kunde vi harleda ledtiden. 

Varje ny anvandarberattelse estimerade vi endast en gang. Vi reviderade 
inte estimaten under tiden vi arbetade med uppgiften. Detta gjorde att vi 
kunde minimera tiden som laget spenderade pa estimering. 




_ Sa hur arbetade vi egentligen? 

Kanban har verkligen fa restriktioner - du kan arbeta pa alia mojliga satt. 
Du kan lata laget arbeta med tidsbestamda aktiviteter eller sa kan du valja 
att utfora aktiviteter nar tillracklig momentum har byggts upp for att 
motivera det. 


Planera Koda Testa Klart 


Trigger- 

punkt 





ko 

redo 



B 

B 


B 

B 

B 


Figur 7 Nar tre uppgifter har inommit uppgiftslistan triggas 
planering/estimering. 

Yi valde att schemalagga tva aterkommande handelser: 

• Dagligt stauppmote - med laget placerat framfor tavlan for 
att lyfta problem och for att hjalpa till att skapa en gemensam 
syn pa de andra lagspelamas uppgifter. 

• Veckovis iterationsplanering - med syfte att planera och 
kontinuerligt forbattra. 
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Iterations- Iterations- Iterations- Iterations- 

planering planering & planering & planering & 
v\ retrospektiv retrospektiv retrospektiv 


Nedbrytning & estimering 


Proj A 


Visualisera komplexitet & f§ teamet 
involverat i problemlosning 


| j 8 abp 
OCIFTfl I 6 ab P 


"Om forutsagbarhet inte ar intressant 
sS ar estimering mindre viktigt." 


Detta fungerade bra hos oss. 

Dagligt stauppmote 


Det dagliga stauppmotet paminde om ett dagligt Scrum-mote. Detta holls 
efter det dagliga ’’Scrum of Scrums”-motet med deltagare fran alia 
funktioner (utveckling, test, driftsattning). ’’Scrum of Scrums” gav viktig 
information till Kanban-teamen, t.ex. vilka problem som skulle tas om 
hand forst och vilka utvecklingsteam som for narvarande hade mest 
problem. I borjan deltog chefema ofta pa dess a dagliga stauppmoten och 
foreslog losningar och prioriterade beslut. Med tiden, allt eftersom 
deltagarna blev battre pa att sjalvorganisera, deltog chefema allt mer 
sallan (men var inte langt bort om de behovdes). 

Iterationsplanering 


En gang i veckan genomfordes iterationsplanering. Yi holl det vaije vecka 
vid en bestamd tidpunkt eftersom vi insag att om vi inte planerade in det 
skulle tiden forbrukas av andra prioriteringar ©. Vi behovde ocksa battre 
kommunikation och kunskapsoverfbring. En typisk agenda var: 

• Uppdatera diagram och tavla. (Fardiga projekt flyttades till en 
“fardigstallandets vagg”. 

• Titta tillbaka pa forra veckan. Vad hande? Varfor da? Vad kan vi 
gora for att forbattra det? 
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• Justering av PA-granser (om nodvandigt) 

• Nedbrytning av uppgifter samt estimer for nytt projekt (vid 
behov) 

I granden var iterationsplaneringen en kombinerad puls av estimering och 
standiga forbattringar. Sma och medelstora fragor lostes pa plats med stod 
av linjecheferna. En svarare provning var att halla greppet om komplexa 
forbattringar. For att hantera detta inforde vi mojligheten for temen att 
tilldela upp till 2 ’’laghinder” till sina chefer. 

Reglerna var som foljer: 

1. En chef kan arbeta pa tva problemluckor vid vaije givet tillfalle. 

2. Om bada ar fulltecknade kan du bara lagga till en ny om du tar 
bort en mindre viktig. 


3. Teamet bestammer nar 
ett problem ar lost. 

Detta var en positiv forandring. 
Plotsligt kunde teamen se att 
chefema aktivt hjalpte dem aven 
med de svara problemen. De 
kunde peka pa hindren och fraga 
”hur gar det?” De skulle inte bli 
bortglomda eller bverkorda av 
en ny prioriteringsstrategi. 

Ett exempel pa ett allvarligt 
hinder var att nar driftteamen 
misstankte att det fanns ett 
produktionsproblemfick de inte den hjalp de behovde ffan utvecklare. De 
behovde den hjalpen for att forsta vilket delsystem som kunde orsaka 
problemet. Men eftersom utvecklama var upptagna med att utveckla nya 
funktioner i sprintarna boijade problemen staplas pa hog. Foga 
forvanande sa upplevde driftteamen att utvecklama inte brydde sig 
tillrackligt om kvalitet. 

Nar detta hinder blottlades eskalerades det forst till linjechefen och sedan 
vidare till avdelningschefen. Han bokade in ett mote med 
utvecklingschefen. I de diskussioner som foljde beslot cheferna att satta 
kvaliteten forst. De mejslade If am en ”round-robin”-losning - for vaije 
sprint skulle ett utvecklingslag halla jour och vara omedelbart tillgangligt 
for att hjalpa driftavdelningen. En stor skillnad var ocksa att 
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utvecklingssidan fran och med nu sa att de skulle lita pa driften om de 
ansag att det var ett allvarligt produktionsproblem. Tills nu hade driften 
varit tvungen att bevisa att det var ett allvarligt problem for att fa deras 
hjalp. 

Efter att ha sakrat stod hos sina chefer lamnade utvecklingschefen over en 
lista pa kontaktpersoner till supportlagen. Det tog fem sekunder fran att 
atgarden annonserades till teamen tills att de satte den pa prov. Men det 
var pa riktigt den har gangen. Ratt forberedelser hade blivit gjorda och 
hindret var overkommet - till stor lattnad for driftteamen. 



29 

Hur vi fann ett planeringskoncept som 
fungerade 


En berattelse 


Jag minns en vandpunkt for ett av teamen. Jag satt med dem i deras andra 
estimeringsmote. Laget hade kort fast i ett projekt som de inte viste hur 
man skulle estimera. Det fanns for manga okanda parametrar och hela 
estimeringsmotet avstannade. Istallet for att ga in och ta over sa bad jag 
dem att forfina processenfor att hitta en bdttre losning. Med sin chef som 
ledsagare tog de sig an uppgiften och borjade skapa en egen losning. 
Denna handelse var en viktigt vandpunkt — en viktig ”,seger ” —fran vilken 
de borjade utvecklas till ett lag med sjalvfbrtroende. Efter detta borjade 
de utveckls sa snabbt att vi var tvunga att sta at sidan. 

Tva manader senare kom deras chef fram till mig efter ett 
retrospektivmdte. "Jag har ett problem ”, sa han och pekade pa Kanban- 
tavlan. ”Vi har inga egentligaproblem. Vad ska vi gora? ” 

Aterupptacka planering 


Planeringspoker pa estimeringsmoten som omfattade alia 
teammedlemmar fungerade inte bra for nagot av teamen. Nagra orsaker: 

1. Kunskapen var ojamn inom laget. 

2. Yanligtvis pratade endast en person. 

3. Lagdeltagama ville ta tag i bradskande arenden som de hade 
lamnat pa sitt arbetsbord. 

Men genom lite experimenterande kom teamen, oberoende av varandra, 
fram till olika estimeringsprocesser. Vaije process fungerade bra for 
respektive team. 
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Tillvagagangssatt 1 - Vaxla och granska 



• For vaije projekt/berattelse: tilldela ett ’’senior + junior”-par som 
far estimera (dvs. en person som kanner val till den aktuella 
berattelsen och en person som inte gor det). Detta hjalper till att 
dela kunskap. 

• De aterstaende lagdeltagarna valjer vilken berattelse som de vill 
estimera (men med en grans pa fyra personer per berattelse for att 
fa effektiva diskussioner) 

• Varje estimeringsgrupp bryter ner sin berattelse till uppgifter och, 
om det behovs, estimerar den. 

• Slutligen byter gruppema berattelser och granskar varandras 
resultat (en person per lag ’’stannar kvar” och forklarar for 
granskarna hur man resonerat) 

• Klart! 

Hela iterationsplaneringsmotet tog typiskt omkring 45 minuter och 
energinivaema var kvar pa en hog niva motet igenom. Vanligtvis gjordes 
1 till 2 justeringar nar berattelserna skickades runt och granskades av nya 
ogon. 
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Tillvagagangssatt 2 - 
senior genomgang, sedan estimering 


Tva seniora medlemmar borjade med att gora en grov genomgang av 
berattelsen/projektet fore planering. Den forsta fragan de stallde sig var 
’’forstar vi tillrackligt om problemet for att skapa en losning?” Om svaret 
var nej retumerade de projektet till uppdragsgivaren. Om svaret var ja 
skapade de en grov losning, i stort vilka teknologier som skulle anvandas. 
Teamet tog sedan over och brot ned projektet till uppgifter med den grova 
losningen som utgangspunkt. 



Figur 8. Nedbrytning till uppgifter med ett annat lag som granskar 
pa iterationsplaneringen. 








_ Vad ska matas? 

Det finns mycket som kan matas - ledtid (tiden det tar fran det att ett 
behov upptacks tills det att behovet ar uppfyllt), hastighet, koer, 
progress... Den viktiga fragan ar: vilka matt kan anvandas for att forbattra 
processen? Mitt rad ar att experimentera och se vad som funkar for er. Vi 
larde oss att progressdiagram var onodigt for projekt som ar kortare an 4 
veckor. Den overgripande framatskridandet kan enkelt faststallas genom 
att titta pa Kanban-tavlan (hur manga berattelser var det i uppgiftslistan 
och hur manga blev klara). 


Potentiellt matt 

For 

Emot 

Ledtid 

Latt att mata. 

Behover inga estimat. 
Boijar och slutar med 
kunden. 

Vager inte in storlek. 

Total hastighet 
(sammanslagning av 
alia arbetstyper) 

En grov men enkel 
indikator for 
forbattring eller 
variation. 

Hjalper inte for att 
prognostisera 
leveransdaum for 
specifika arbetstyper. 

Hastighet per 
arbetstyp 

Mer precist an totalt 
hastighet. 

For att vara anvandbart 
maste det starta fran 
kundbehovet och folja 
hela vagen till 
leverans. 

Tar lite langre tid att 
folja jamfor med total 
hastighet. 

Kolangder 

En snabb indikator av 
behovsfluktuationer. 

Latt att visualisera. 

Sager inget om orsaken 
ar ojamnt inflode av 
behov eller ojamn 
kapacitet. 

En kolangd pa noil kan 
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| | | indikera overkapacitet. | 

Vi borjade med att mata “hastighet per arbetstyp” och “kolangder”. 
Hastighet per arbetstyp ar enkelt att mata och ar anvandbart. Kolangder ar 
bra huvudindikatorer eftersom de kan upptackas omedelbart (nar du vet 
var du ska hitta dem). 
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Figur 9. Flakshalsar och mojligheter. Den roda cirkeln visar hur koer 
har byggts upp och avslojar flaskhalsar i test. Franvaron av ko i 
uppgiftslistan i supportkolumnen indikerar att det inte ar nagon 
vantetid for nytt supportarbete. Detta ar ett gott tecken pa hog 
kundserviceniva. 

Vi anvande inte kumulativa flodesdiagram men det kunde varit intressant. 


Antal uppgifter 



Tid 
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Vi anvande inte kumulativa flodesdiagram eftersom Kanban-tavlan och 
hastighetsdiagrammet gav oss tillrackligt med information. Atminstone i 
tidiga mognadsfaser. Flaskhalsar, ojamnhet och for mycket arbete kan 
kunde anda enkelt identifieras och att losa det holl oss sysselsatta de forsta 
sex manaderna. 
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Hur saker och ting borjade forandras 

Tre manader efter att Kanban inforts gav ledningen system- 
administrationsteamet utmarkelsen “bast presterande lag” pa IT- 
avdelningen. Samtidigt rostades samma team fram som en av de tre mest 
’’positiva erfarenhetema” i foretagets retrospektiv. Foretagets retrospektiv 
ar en foretagsomfattande aktivitet som intraffar var 6:e vecka och detta 
var forsta gangen som ett team hamnade pa topp-3-bstan! Och bara 3 
manader tidigare besvardes dessa lag av flaskhalsar som de fiesta klagade 
pa. 


Tjanstekvaliteten hade okat. Sa hur gick det till? 

Det vasentliga ogonblicket var nar alia borjade dra tillsammans. Cheferna 
gav ett tydligt fokus och skyddade teamen fran arbete som inte var deras 
och teamen tog ansvar for kvalitet och deadlines. Det tog ungefar tre till 
fyra manader innan detta intraffade men efter det sa flot det pa. Alla 
problem forsvann inte (da skulle vi alia vara utan arbete, eller hur? ©) 
men vi stalldes infor nya utmaningar som ”hur halier vi laget motiverat 
for fortsatta forbattringar (nar inte de sjalva langre ar flaskhalsen)”. 

En viktigt bit i sjalvorganiseringspusslet var inforandet av konceptet med 
”en driftskontakt per utvecklingsteam”. Det innebar att varje 
utvecklingsteam fick sin egen supportkontakt pa driftsavdelningen. 
Kanban gjorde detta mojligt genom att tillata teammedlemmarna att 
sjalvorganisera arbetet, undvika overtid och mojliggora standig 
forbattring. Forat tog nagon person, slumpmassigt vem, en uppgift fran 
kon, loste det efter basta formaga och fortsatte sedan med nasta uppgift. 
Kommunikationsbrister innebar att man tvingades boija om fran boijan 
med ett nytt loggat arende. Nar ett-till-ett-konceptet infordes gavs 
supportlaget plotsligt mojligheten att respondera snabbt nar daligt data 
eller kvalitetsproblem hotade systemet. 

Snabbt utvecklades egenanpassade kommunikationsprotokoll, tex. 
Borjade driftspersonalen anvanda chat for att prata med utvecklare som de 
kande val, e-post for de som skrev battre an de pratade och telefon om det 
var det snabbaste sattet att losa problemet ©. 
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Fore 



Figur 10. Fore: Forsta linjens chef ar huvudkontakten for lagen. Allt 
viktigt som maste goras gar genom honom. Sma saker, vanligtvis 
utvecklarnas problem, tas emot via ett arendehanteringssystem. Fa 
direkta person-till-person-interaktioner. 
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Efter 



Figur 11. Efter: “en driftskontakt per utvecklingsteam” infordes. 
Utvecklingslagen pratar direct med en utsedd kontaktperson pa 
driftsavdelningen. Manga interaktioner person-till-person. 
Driftslagets spelare sjalvorganiserar sitt arbete med hjalp av 
Kanban-tavlan. Chefen byter fokus till att prioritera stora projekt 
och att ge stod nar svara problem uppstar. 

Sa hur paverkades teamens prestationer? 
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Systemadminlagets hastighet 



Sprint 


Figur 12. Total hastighet och projekthastiget, matt i antalet fardiga 
berattelsepoang per vecka. Totalen ar suraraan over alia kolumner. 
Projekthastigheten representerar den del som tillagnades ’’projekt” 
(storre arbetsuppgifer som att uppgradera en hardvaruplattform). 
De tva dalarna sammanfaller med 1) en vecka da nastan alia 
teammedlemmar reste och 2) en stor leverans fran utveckling. 

Saledes visade laget en allmant positiv trend. Samtidigt hade laget 
investerat i kunskapsdelning och teamarbete. 
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Och nar vi anda halier pa, lat oss kolla pa DB-adminlagets prestation. 


DB-adminlagets hastighet 



Figur 13. Total hastighet och sma supportuppgifter. Dalarna i mitten 
sammanfaller med julledigheten. 

Trenden for total hastighet ar uppatgaende aven om variansen ar 
betydande. Variansens storlek inspirerade teamet att overvaka antalet sma 
supportarenden (uppgifter som ar for sma for att kvalificera sig till 
Kanban-tavlan). Som du ser visar grafen en tydlig omvand korrelation 
mellan antalet sma supportarenden och den totala hastigheten. 

Supportlaget borjade med Kanban senare an de andra tva lagen sa vi har 
annu inte sarskilt mycket palitlig data. 

Vaxande mognad 

Nar vi borjade var det latt att hitta problemomraden. Men att identifiera 
den storsta mojligheten till forbattring var svart. Kanbantavlan gav en 
mycket stor transparans. Det var inte bara enklare att identifiera problem 
utan viktiga fragor lyftes om flode, varians och koer. Vi borjade anvanda 
koer som ett verktyg for att identifiera problem. Fyra manader efter att de 
boijat med Kanban borjade cheferna jaga orsakema till varianser som 
paverkade lagen negativt. 

Allt eftersom teamen utvecklades fran individer till sjalvorganiserade 
enheter upptackte cheferna att de stod infor en helt ny typ av utmaningar i 
sitt ledarskap. De tvingades allt mer att hantera personalfragor — hantera 
klagomal, definiera gemensamma mal, losa konflikter och forhandla 
overrenskommelser. Inte en helt smartfri forandring - de anmarkte oppet 
att det tog mycket kravdes bade skicklighet och energi for att lara sig det. 
Men antog utmaningen och blev darmed ocksa biittre ledare. 
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Allmanna lardomar 


Nar pagaende arbete minskar 
okar begransningarna 


Samtliga lag borjade med ratt generosa PA-granser. Da lades mest energi 
pa att forsoka skapa flyt och att sakerstalla att organisationen fick den 
support den behovde. 

Till att borja med vill chefema kora flera projekt samtidigt men inom 
nagra veckor blev det tydligt att det inte fanns tillracklig kapacitet for att 
hantera de lagprioriterade projekten. Det kravdes bara en snabb blick pa 
tavlan for att inse att inte nagon av de lagprioriterade uppgifterna 
paborjades. Detta foranledde chefema att minska antalet projekt per lag. 

Med tiden, nar flodet for de hogprioriterade uppgifterna blev stabilare, 
boijade vi dra ner PA-granserna. Det gjorde vi genom att minska antalet 
pagaende projekt (kolumner) fran tre, till tva och sedan ett. Nar detta 
skedde boijade begransingar utanfor laget blottlaggas. Teammedlemmar 
boijade rapportera att de inte fick hjalp fran utomstaende i tid varpa 
chefema vande sin uppmarksamhet dit for att hantera det. 
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Bland de saker som uppdagades var hur tydlligt daligt resultat fran andra 
team paverkade var prestation. Det var svart att bibehalla ett mjukt och 
snabbt flode nar inkommande uppgifter hela tiden behovde rattas till. 

De har problemen var inte helt osynliga innan vi satte igang. Det vara 
snarare en fraga om ”vilka problem ska vi hantera forst” och att na 
konsensus kring det. Genom Kanban-tavlan kunde alia se hur specifika 
problem paverkade flodet och det gjorde det lattare att samla momentum 
att ta itu med prolemen over organisationsgranserna. 

Tavlan forandras med tiden, 
hugg inte utseendet i sten 


Alla Kanban-tavlor forandras med tiden. Det tar vanligtvis tva till tre 
omarbetningar innan laget hittar en som fungerar bra. Att lagga mycket tid 
pa den forsta layouten ar darfor troligen bortkastat. Se till att du enkelt 
kan bygga om tavlan. Vi anvande svart tejp for var layout. Det gjorde det 
latt att arrangera om tavlan och kunde anvandas pa vaggar saval som pa 
vita tavlor. Ett annat satt jag har sett ar att rita tavlans rutnat med en tjock 
markpenna (men se till att det gar att ta bort! ©) 

Nedan syns ett typiskt exempel pa en optimerad layout. Prioriteterna 
andrades mycket i boijan sa istallet for att behova flytta en hel kolumn 
med lappar fram och tillbaka satte laget prioriteten ovanfor vaije kolumn. 



Figur 14. Tidig Kanban-tavla med lappar for aktuell prioritet. 
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Var inte radd for att experimentera och misslyckas 

Lardomen jag fick av detta aventyr var att det faktiskt inte finns nagon 
slutpunkt. Misslyckandet sker i det ogonblick vi tror att det finns det. Det 
finns bara en ett andlost experimenterande och larande. Att aldrig 
misslyckas betyder att aldrig lara sig. Yi misslyckades flera ganger pa 
vagen (dalig tavel-layout, estimeringar, redundanta progressdiagram, etc.) 
men varje gang larde vi oss nagonting nytt och viktigt. Om vi hade slutat 
forsbka, hur skulle vi da kunna lara oss? 

Framgangen med Kanban har nu ocksa inspirerat bade chefsema och 
Scrumteamen att experimentera med Kanban. Kanske kan denna bok vara 
till hjalp! 




Nagra sista ord pa vagen 


Borja med retrospektiven! 


Manga mojligheter och mycket att tanka pa, eller hur? Hoppas den har 
boken hjalpte till att skingra dimman. Det funkade i alia fall for oss :o) 

Om du ar intresserad av att forandra och forbattra din process, lat oss ta 
ett beslut at dig redan nu. Om du inte gor retrospektiv regelbundet sa borja 
med det! Och se till att de leder till verklig forandring. Skaffa en extern 
facilitator om det behovs. 

Nar ni val har effektiva retrospektiv pa plats har ni boijat er resa i att ta 
fram precis den ratta processen for er situation - oavsett om den ar 
baserad pa Scrum, XP, Kanban, eller en kombination av dessa, eller nagot 
annat. 


Sluta aldrig experimentera! 


Kanban och Scrum ar inte malet — kontinuerligt larande ar det! Snabb 
aterkoppling ar nyckeln till larande. Sa anvand aterkopplingen! Ifragasatt 
allt, exeperimentera, misslyckas, lar och exeperimentera igen. Bekymra 
dig inte om att gora allt ratt fran borjan for det kommer du anda inte att 
lyckas med! Bara boija nagonstans och utveckla darifran. 

Det enda riktiga misstaget ar att inte lara fran sina misstag! 

Som sagt, det ar dar du kan lara sig mest. 

Lycka till och glom inte att ha kul pa vagen! 


/Henrik & Mattias, Stockholm 2009-06-24 
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H: Vardetallt? 

M: Jag tror det. Vi slutar heir. 

H: Vi kanske ska saga vilka vi dr? 

M: Bra poang. Om vifar det att verka som att vi dr ett par 
trevliga killar safar vi kanske konsultuppdrag. 

H: Jamen, da gor vi det! Sen far det racka. 

M: Ja, vi har annat att gora och det har lasarna ocksa. 

H: Faktum dr att min semester borjar nu :o) 

M: Horru, var lagom kaxig. 



Om forfattarna 


Henrik Kniberg och Mattias Skarin ar konsulter pa Crisp i Stockholm. De 
tycker om att hjalpa foretag att lyckas med bade den tekniska och 
manskliga sidan av programvaruutveckling och de har hjalpt dussintals 
foretag att omsatta Lean och Agila principer i praktiken. 

Henrik Kniberg 

Det senaste artiondet har Henrik varit utvecklingschef pa 3 
svenska IT-foretag och hjalp manga fler att forbattra sina 
processer. Han ar certifierad Scrum-utbildare och arbetar 
regelbundet med pionjarer inom Lean och Agile som Jeff 
Sutherland, Mary Poppendieck och David Anderson. 

Henriks forra bok, “Scrum and XP from the Trenches” har mer an 
150,000 lasare och ar en av de mest populara bockerna i amnet. Han har 
fatt pris for basta talare flera ganger for presentationer pa internationella 
konferenser. 

Henrik vaxte upp i Tokyo och bor nu i Stockholm med sin fru Sophia och 
tre bam. Pa fritiden ar han aktiv musiker och komponerar musik och 
spelar bas och keyboard i lokala band. 

henrik.kniberg @ crisp, se 

http://blog.crisp.se/henrikkniberg 

http://www.crisp.se/konsulter/henrik.kniberg 



105 



1061 Kanban and Scrum - det basta av tvA varldar 


Mattias Skarin 

Mattias arbetar som Lean-coach och hjalper programvaru- 
foretag dra nytta av Lean och Agile. Han handleder pa alia 
nivaer, fran utvecklare till ledning. Han har hjalp ett 
spelforetag att minska utvecklingstiden fran 24 till 4 
manader, aterstallt fortroendet hos en hel utvecklings- 
avdelning och var en av de forsta pionjarema i Kanban. 

Som entreprenor har han varit med och grundat och drivit tva foretag. 

Mattias har en civilingenjorsexamen i kvalitetsledning och har arbetat 
som utvecklare av verksamhetskritiska system i 10 ar. 

Han bor i Stockholm, gillar rock ’n’ roll, dans, racing och skidakning. 

mattias. skarin @ crisp, se 

http://blog.crisp.se/mattiasskarin 

http://www.crisp.se/konsulter/mattias.skarin 




